2023-q3

Mon, 01 Jan 2024 23:22:00 +0100

Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q3 of 2023! Details.

Joan Lledo modified the PCI arbiter to prevent mapping I/O region files. He previously sent some patches to implement mapping region and ROM files using mmap(). However, a BAR region can represent either memory or I/O space, and only memory should be allowed to be mapped. Since I/O BARs only contain I/O addresses, he went ahead and prevented the mapping of I/O region files. The next step is to make IO spaces available for users through the pci-arbiter. He plans to add a new RPC that checks for permission and calls i386_io_perm_create(). Then it returns the resulting port.

Our Google summer of code student Vedant Tewari decided to port rust, and the rust porting effort is making good progress. The build process is a bit wonky, and Debian is using an older rust version. Check out the rust pull request that adds Hurd support!

Samuel worked on setting up PAE, which will eventually let us use more than 4GB of RAM on a 32-bit Hurd! It is also useful for the X86_64 architecture. He also fixed the jemalloc build.

Samuel was incredibly productive this quarter making the X86_64 bit port more stable. He fixed the 64-bit Hurd PIE build, and he got git working on the 64-bit port! Though a few of the git tests are failing on both X86_64 and the 32 bit port. He fixed the glibc build, which involved fixing pmap_remove and pmap_protect. He discovered that core dumping is currently causing problems on the 64-bit port, and he temporarily encourages people to disable core dumping. Samuel fixed some networking issues and a dpkg issue for the 64-bit port. It was hard to discover what the problem was, because the debugging tools have not been ported to the 64-bit port. He add some helpers to locking to fix some bugs, and he encourages other developers to help him fix the debugging tools for X86-64. It seems that most developers are currently running the 64-bit Hurd in a virtual machine and not in real hardware.

Luca Dariz got a patch series merged for the 64 bit port.

Sergey implemented MAP_EXCL and provided MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL) as well other mmap work. He explains:

MAP_FIXED is defined to silently replace any existing mappings at the address range being mapped over. However, this is dangerous and only rarely desired behavior.

Various Unix systems provide replacements or additions to MAP_FIXED.

SerenityOS and Linux provide MAP_FIXED_NOREPLACE. If the address space already contains a mapping in the requested range, Linux returns EEXIST. SerenityOS returns ENOMEM, however that is a bug, as the MAP_FIXED_NOREPLACE implementation is intended to be compatible with Linux.

DragonFly BSD, NetBSD, and OpenBSD provide MAP_TRYFIXED, but with different semantics. DragonFly BSD returns ENOMEM if the requested range already contains existing mappings. NetBSD does not return an error, but instead creates the mapping at a different address if the requested range contains mappings. OpenBSD behaves the same, but also notes that this is the default behavior even without MAP_TRYFIXED (which is the case on the Hurd too).

Since the Hurd leans closer to the BSD side, add MAP_EXCL as the primary API to request the behavior of not replacing existing mappings. Declare MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL), so any existing software that checks for either of those macros will pick them up automatically. For compatibility with Linux, return EEXIST if a mapping already exists.

Damien Zammit added a USB mass storage translator via rumpusbdisk. Though it has some issues as he explains:

Netdde sneems to exhibit a bug when running ifdown /dev/eth0 simultanously to running the rumpusbdisk translator, because to the two devices share the same IRQ.

Damien also worked on the Hurd's SMP support (much of his SMP contributions is based on the earlier work done by Almudena Garcia):

He tweaked GNU Mach's scheduler, and he merged three GNU Mach commits.

He added a show all runqs command to GNU Mach's kernel debugger.

He also improved SMP in GNU Mach by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number from an offset in the percpu area. Further improvements can be made by using other percpu areas. It was untested on 64 bit.

Damien also taught GNU Mach to use the x86 CPUID instruction to get the CPU ID for speed. He reduced the time it takes to get the CPUID. He made it 100 times faster!

He mentioned some issues: 60% of the time, booting a 32 bit Hurd, with SMP enabled, fails to boot (sometimes apparently getting stuck in the rumpdisk). When it does boot, it is not particularly stable and likely to crash.

Essentially, the SMP work is progressing, but it is not ready for production use. His recent work made the non-SMP faster, and a 32 bit Hurd, with SMP enabled and only one core, appears relatively stable (but slow to boot). The 32-bit SMP enabled Hurd may soon be as fast as the non-SMP Hurd. Eventually the SMP enabled Hurd will be faster than a non-SMP Hurd.

Flavio Cruz halved the size of mach_msg_type_long_t, from 16 to 8 bytes. He also simplified the overall 64bit RPC ABI, removing "holes" in mach_msg_type_t or mach_msg_type_long_t, which prevents possible leakages to userspace.

Some Hurd people talked to Kent Overstreet, the author of bcachefs to discuss the possibility of porting Linux's newest filesystem to the Hurd; the conversation was recorded. While most Hurd developers believe that it would possible to port bcachefs to the Hurd, all agree that it would be difficult to port and hard to maintain. No Hurd developers are currently planning or working on porting bcachefs to the Hurd. But perhaps you want to?

So if you want to test if your favorite packages work on the Hurd and contribute towards making the full GNU system usable for a wider range of people, please check the contributing page.