Merge branch 'master' of flubber:~hurd-web/hurd-web

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...