open_issues/implementing_hurd_on_top_of_another_system: New.

1 files changed, 63 insertions, 0 deletions

diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
new file mode 100644
index 00000000..ea06da44
--- /dev/null
+++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
@@ -0,0 +1,63 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+It is possible to run Hurd stuff on top of another system instead of on Mach.
+One obvious variant is emulation ([[hurd/running/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