diff options
| -rw-r--r-- | open_issues/implementing_hurd_on_top_of_another_system.mdwn | 63 |
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 |