[vezzy-fnord]

It isn't. For one thing, it's a port of an old OSF Mach kernel. Hurd uses GNU Mach, which is descended from CMU Mach 3.0. They don't support memory objects, their threading is bare bones, they assume a bootstrap server and there would be no way to actually get glibc and Hurd RPC working.

[sergiolp]

The OSF vs GNU Mach thing is not a problem. It was years ago, but I managed to run a Hurd translator statically linked against a slightly modified glibc on OSF Mach (the one bundled with MkLinux, you can see its code on my repo https://github.com/slp/mkunity).

In fact, if you look at Mach support code on glibc's code, you'll see build time conditionals for supporting non-GNU Mach versions.

The bootstrap server is not a problem either, but the lack of memory object would indeed break all libpager based translators, among other stuff.

As a PoC, I wrote a filesystem translator (https://github.com/slp/anonfs) which doesn't rely on memory objects, implementing conventional read/write semantics (no mmap() support, though).

[vezzy-fnord]

The option of using MkLinux as a host has been raised as a hypothetical since many years ago, but was never tried. I don't have spare PPC hardware in mind, but that's interesting to hear it works.

Porting the NextBSD work to the Linux kernel API is certainly something on my list in case rump integration for Hurd doesn't pan out, in any event.