It is possible to run Hurd stuff on top of another system instead of on Mach. One obvious variant is emulation (using QEMU, for example), but doing that does not really integratable the Hurd guest into the host system. There is also a more direct way, more powerful, but it also has certain requirements to do it effectively:

IRC, #hurd, August / September 2010

<marcusb> silver_hook: the Hurd can also refer to the interfaces of the
  filesystems etc, and a lot of that is really just server/client APIs that
  could be implemented on any system that has transferable rights to
  message capabilities.
<marcusb> silver_hook: it's surprising how few systems *have* transferable
  rights, though!
<marcusb> silver_hook: usually it is added as an afterthought
<marcusb> and comes with restriction
<youpi> marcusb: there's SCM_RIGHTS to transfer fds, which is quite often
  available
<marcusb> youpi: yes, I know this as "fdpassing"
<marcusb> youpi: it's described in the Stevens series even
[...]
<marcusb> ArneBab: well, let me put it this way.  the Linux kernel has no
  interface to manipulate another tasks's virtual address space, ie you
  can't map/unmap stuff in another process
<marcusb> ArneBab: you would have to use ptrace and load some stub code in
  that process to make that happen.
<marcusb> ArneBab: so for complete transparent manipulation, you need a
  kernel module
<marcusb> that is what the User Mode Linux kernel module does
<marcusb> ArneBab: so say you use the User Mode Linux kernel module for
  that one feature.  Then you can do everything that User Mode Linux can
  do, which, I assure you, includes running subhurds :)
<marcusb> it can be a bit tricky to implement those features, but it is not
  harder than writing a kernel in the first place
<ArneBab> So, if I got an admin to install User Mode Linux and Mach
  emulation, I’d get the flexibility (and independence from admin
  decisions) I have in the Hurd?
<marcusb> ArneBab: one problem is that you still use Linux.  For those who
  want to get rid of Linux for political reasons, that would mean complete
  failure
<marcusb> ArneBab: if you have UML kernel module, you can implement Mach in
  user space
<marcusb> ArneBab: in fact, John Tobey did this a couple of years ago, or
  started it

(tschwinge has tarballs of John's work.)

<marcusb> ArneBab: or you can just implement parts of it and relay to Linux
  for the rest
<marcusb> the point is, that if you don't care for kernel improvements, and
  are sufficiently happy with the translator stuff, it's not hard to bring
  the Hurd to Linux or BSD

Continue reading about the benefits of a native Hurd implementation.

IRC, #hurd, 2010-12-28

<antrik> kilobug: there is no real requirement for the Hurd to run on a
  microkernel... as long as the important mechanisms are provided (most
  notably external pagers and Mach IPC), the Hurd could run an top of
  pretty much any kernel...
<antrik> whether it makes sense is another question of course :-)
<antrik> though I must say that I'm more and more convinced running the
  Hurd on top of a monolithic kernel would actually be a useful approach
  for the time being...

IRC, #hurd, 2011-02-11

<neal> marcus and I were discussing how to add Mach to Linux
<neal> one could write a module to implement Mach IPC
<neal> and another to implement Mach VM
<neal> the big thing missing with Mach VM is the ability for a tracing
  process to easily map or unmap an inferior process's memory
<antrik> neal: why would a tracing process need to map the inferior's
  memory?
<neal> the simple answer is that is how it is done on Mach
<antrik> neal: is it? not sure we are talking about the same thing
  here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK
<neal> on linux?
<neal> I think it use /proc/pid/mem
<antrik> on Hurd
<neal> I'm talking about adding Mach to Linux
<neal> by adding some functionality to Linux
<neal> and then implementing a bunch in user space
<antrik> yeah, but I don't understand the point about mapping inferior's
  memory :-(
<antrik> what would be in user space?
<neal> there are a number of different cut points
<neal> one could imagine just using Linux's device drivers, CPU scheduler,
  memory management, etc.
<neal> another possibility would be something higher where Hurd processes
  just use some Hurdish servers
<antrik> neal: yeah, these are all options I have been considering... too
  bad I wasn't able to come to FOSDEM -- I'd love to have participated in
  this discussion :-(
<antrik> neal: BTW, were you just discussing this as a hypothetical idea,
  or something you are seriously considering?
<neal> I'm unlikely to work on it, sorry
<antrik> didn't really expect that :-)
<antrik> would be nice though if you could write up your conclusions...