summaryrefslogtreecommitdiff
path: root/Hurd/NeighborHurd.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'Hurd/NeighborHurd.mdwn')
-rw-r--r--Hurd/NeighborHurd.mdwn21
1 files changed, 19 insertions, 2 deletions
diff --git a/Hurd/NeighborHurd.mdwn b/Hurd/NeighborHurd.mdwn
index 5a9020fc..ed76c4e1 100644
--- a/Hurd/NeighborHurd.mdwn
+++ b/Hurd/NeighborHurd.mdwn
@@ -1,3 +1,20 @@
-<http://www.gnu.org/software/hurd/howto/subhurd.html>
+It is possible to run multiple instances of the Hurd
+in parallel, on a single instance of Mach. Other than
+performance crosstalk, they are essentially isolated.
+Practically, as many devices do not allow multiple
+non-cooperating users, e.g., hard drive and network
+this is not currently possible. It can be overcome,
+however, by virtualizing these problematic devices.
--- [[Main/GrantBow]] - 21 Jan 2003
+When extra hardware is not available, it is possible to
+use a sub-hurd. A sub-Hurd is like a neighbor Hurd,
+however, makes use of some resources provided by another
+Hurd. For instance, backing store and the console.
+
+Sub-hurds are extremely useful for debugging core
+servers as it is possible to attach to them with gdb
+from the parent. This avoids deadlock, e.g., when the
+instance of gdb stops the server but requires its use.
+(Note: it is possible to use [[NonInvasiveDebugging]],
+but this is less flexible.) A [tutorial](http://www.gnu.org/software/hurd/howto/subhurd.html)
+on setting up sub-hurds is available.