IRC channel logs

<solid_black>and merry christmas :)

<azert>Good solstice! May the light be with you

<damo22>i might have a go at refactoring acpi_init tomorow

<damo22>the acpi_get_irq_number() looks broken

<damo22>from what i understand now, we are supposed to locate the _PRT on the pci root port (\SB.PCI0._PRT) and that should have all the pci irq settings

<damo22>but we seem to be walking all the acpi devices

<solid_black>vm_map_enter coalescing optimizations fails to check needs_copy

<solid_black>and it's my feault

<solid_black>apparently nothing has broken because of this yet?

<solid_black>we don't have minherit? how come?

<solid_black>I... think I understood how "copy VM objects" (not to be confused with vm_map_copy_t) actually work

<solid_black>only took me several days of reading VM code :)

<solid_black>various things make a lotmore sense now

<solid_black>if we could change 'boolean_t copy' of vm_map() into a tri-state VM_COPY_NONE / VM_COPY_BOTH / VM_COPY_MAPPING (last one needs a better name), we could make it so that VM_COPY_MAPPING causes entry->needs_copy to be set, but the VM object would not get copied

<solid_black>so then if MAP_COPY is passed, you get VM_COPY_BOTH, and a full (if internally delayed) snapshot of the object at the moment of copy

<solid_black>and if MAP_COPY is not passed, you get VM_COPY_MAPPING / the POSIX behavior of the mapping possibly changing under you if the underlying object/file is itself modified, but your own writes to the mapping resulting in it getting CoWed

<solid_black>vm_object_copy_temporary looks like it should be folded into vm_object_copy_strategically

<Pellescours>if saw some book references at the top of vm_vages.c, I will try to learn a bit here :)

<Guest37>Greetings room, when will the gnu/hurd system start running ? Another year ends, and Hurd is still dead for real hardware.

<gnu_srs>Guest37: No it is not dead for real HW. Just follow stuff here and at bug-hurd@gnu.org !

<Guest37>Have you tested hurd on real hardware of 64 bits ? gnu_srs

<gnu_srs>Guest37: Not yet. But other people has. I'm currently running GNU/Hurd on qemu images.

<Guest37>But qemu there is not even how to install graphically on windows 10, pure terminal is seen the installation gnu_srs

<azert>Guest37: 64-bit support is very recent, I’d not advise running that. In any case, I’d say that Hurd on symmetric multiprocessing in 64-bit mode on real hardware running a free firmware is not very far ahead. We are at a point where any fix that is pushed daily by the Hurd hackers gets us a little bit closer to that.

<azert>We might get WiFi on 32-bit before that happens. Would be interesting and nice

<Guest37>Hopefully they will fix the Hurd kernel, so we can have a complete system running on a 64-bit multi-processor machine. azert

<azert>Guest37: not an English native speaker?

<azert>I’d work on my English if I was you, hopefully you’ll fix it

<jab>Guest37: You are always welcome to help us improve the Hurd.

<sneek>jab, you have 1 message!

<sneek>jab, azert says: I understand the wish to share good news with phoronix, but beware of the demoralization shills over there! Don’t fall for their tricks, don’t reply to the inevitable out of context wrong criticisms expressed with weird standing of superiority and paternalism

<jab>We have a couple of developers that are not native english speakers doing significant work on the Hurd.

<azert>jab: I’m sure that Guest37 didn’t mean to complain, but it sounded that way to me. I’m also sure he didn’t try what is there, since the Hurd doesn’t have an installation wizard

IRC channel logs

2024-12-25.log