January 6, 2024 at 3:20 PM, "Sergey Bugaev" <buga...@gmail.com> wrote:
> > On Sat, Jan 6, 2024 at 10:47 PM jbra...@dismail.de <jbra...@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? I'll fix that. > > > > > +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? What can I say? It was an improvement right? How? Lowered memory usage? > > > > +Sergey is also working on [[porting the LadyBird web > > > > +browser|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00013.html]] > > > > We spell Ladybird with a lowercase b. You could also link to > https://ladybird.dev/ here. > > > > > +to the Hurd. The author of this post uses the [[netsurf web > > +browser|https://www.netsurf-browser.org/]] on the Hurd, which works on > > +simple websites like wikipedia, but it badly renders javascript heavy > > +websites, which makes many websites un-useable. If Sergey is > > +successful in porting LadyBird, then Hurd users could start using > > +sites like Github! > > > > Let me show you something (see the attachment :) > > See also [0] for a recent update on Ladybird development; there are > live demos in the second half of the video. > > [0]: https://youtu.be/jagkQMbfqJY > > > > > +Sergey also started [[porting the Hurd to > > > > +AArch64!|https://lists.gnu.org/archive/html/bug-hurd/2023-12/msg00110.html]] > > +While a port to RISC-V might be more exciting, > > > > What I meant there is that RISC-V itself is more exciting, because > it's an open architecture and so on. As far as Hurd ports go, both > ports would be equally exciting to me. In fact, aarch64-gnu might be a > little bit more exciting exactly because I do have the hardware to run > it, today. > > > > > it is worth mentioning > > +that AArch64 is more established. What is interesting is that Sergey > > +is already able to build Hurd servers for AArch64! Normally, in order > > +to run the binaries, one would port GNUMach to AArch64. Luckily for > > +us, Sergey is a genius. > > > > I wish :D > > > > > He was able to run a 'Hello World' Hurd > > +AArch64 binary on Linux in GDB! This helped him fix some bugs along > > +the way. We still need to define the ABI and complete the GNUMach > > +port, but this is exciting news! > > + > > +Tobias Platen started [[porting GNUMach to > > > > +Power9|https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00021.html]]. > > > > Wait, how did I miss this? And I see that discussion even referenced > Darling!? (and no one cc'd me *despite* talking about Darling?) If > that is going somewhere (though it seems stalled?), should I be > hacking on PPC userland? Give it a shot if you want. Definitely reach out to Tobias! > Sergey >