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 | 45 |
1 files changed, 23 insertions, 22 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 1d7a1e50..7e88e322 100644 --- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -21,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 @@ -33,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 @@ -57,10 +58,10 @@ 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]]. |