diff options
Diffstat (limited to 'open_issues/implementing_hurd_on_top_of_another_system.mdwn')
| -rw-r--r-- | open_issues/implementing_hurd_on_top_of_another_system.mdwn | 63 |
1 files changed, 39 insertions, 24 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 index a3e367ce..23512aa9 100644 --- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -11,7 +11,8 @@ 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 +One obvious variant is [[emulation]] (using [[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: @@ -20,8 +21,8 @@ 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. + 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 @@ -32,23 +33,24 @@ IRC, #hurd, August / September 2010 <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 + 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> 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 + <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 @@ -56,10 +58,23 @@ IRC, #hurd, August / September 2010 ([[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 + <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: [[benefits]].) +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... |