From 5c47a316cb008d2a1ce91977803a59359e35b9a8 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 7 Oct 2010 00:00:15 +0200 Subject: open_issues/implementing_hurd_on_top_of_another_system: New. --- ...implementing_hurd_on_top_of_another_system.mdwn | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 open_issues/implementing_hurd_on_top_of_another_system.mdwn 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 + + 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. + silver_hook: it's surprising how few systems *have* transferable + rights, though! + silver_hook: usually it is added as an afterthought + and comes with restriction + marcusb: there's SCM_RIGHTS to transfer fds, which is quite often + available + youpi: yes, I know this as "fdpassing" + youpi: it's described in the Stevens series even + [...] + 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 + ArneBab: you would have to use ptrace and load some stub code in that + process to make that happen. + ArneBab: so for complete transparent manipulation, you need a kernel + module + that is what the User Mode Linux kernel module does + 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 :) + it can be a bit tricky to implement those features, but it is not + harder than writing a kernel in the first place + 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? + 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 + ArneBab: if you have UML kernel module, you can implement Mach in + user space + ArneBab: in fact, John Tobey did this a couple of years ago, or + started it + +([[tschwinge]] has tarballs of John's work.) + + ArneBab: or you can just implement parts of it and relay to Linux for + the rest + 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 -- cgit v1.2.3