On Sat, Jan 6, 2024 at 10:47 PM jbranso@dismail.de <jbranso@dismail.de> wrote:
+Luca Dariz worked on adding [[some simple GNUMach user-space tests
I've never seen gnumach spelled like that (GNUMach), only GNU Mach or
gnumach. Is that intentional?
+Flavio Cruz [[improved GNUMach's
+IPC|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00033.html]]
+by reordering `mach_msg_type_t` fields to byte align `msgt_name` and
+`msgt_size`. He also created a patch series to [[avoid message
+resizing for
+x86_64|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00028.html]].
+He also [[removed untyped mach RPC
+code|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00026.html]],
+since the Hurd always uses typed Mach RPC.
It's not that much that *the Hurd* uses typed IPC, it's that gnumach
does. The Hurd could easily support either, and in fact this support
was present (though likely bitrotten), and this is what Flavio has
removed. This is because going forward, we don't see the Hurd running
on any other flavor of Mach; but it was originally the goal for it to
run on non-GNU Machs, IIRC.
+Sergey Bugaev added [[GNUMach entry re-coalescing
+support|https://darnassus.sceen.net/~hurd-web/open_issues/gnumach_vm_map_entry_forward_merging/]].
+Essentially, Mach is not always able to merge two vm entries that are
+made next to each other, which slows down ext2 and bash. Sergey
+allowed GNUMach to merge entries in the common cases, which greatly
+helps ext2fs.
Is that actually true though — did it speed anything up?