summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--open_issues/implementing_hurd_on_top_of_another_system.mdwn63
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