From a63eb8b0eae2828ef71fa4d5962f967072902b4d Mon Sep 17 00:00:00 2001 From: GNU Hurd wiki engine Date: Wed, 22 Aug 2007 14:23:06 +0000 Subject: web commit by NealWalfield: Explain --- Hurd/NeighborHurd.mdwn | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) (limited to 'Hurd') 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 @@ - +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. -- cgit v1.2.3