diff options
Diffstat (limited to 'hurd/subhurd.mdwn')
| -rw-r--r-- | hurd/subhurd.mdwn | 80 |
1 files changed, 73 insertions, 7 deletions
diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 5b132604..f2117ead 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A sub-Hurd is like a [[neighbor_Hurd|neighborhurd]], however, makes use of some resources provided by another Hurd. For instance, backing store and the @@ -17,7 +18,10 @@ attach to them with gdb from the parent ([[debugging_via_subhurds|debugging/subhurd]]). This avoids deadlock, e.g., when the instance of gdb stops the server but requires its use. (Note: it is possible to use [[debugging/gdb/noninvasive_debugging]], but this is less -flexible.) +flexible.) Vice versa, it is also possible to use a subhurd to debug the +*main* Hurd system, for example, the latter's root file system. + +[[!toc levels=2]] # Howto @@ -27,7 +31,7 @@ flexible.) To run a subhurd, you need an additional partition with an installed Hurd system. In principle, you can also use your main partition in read-only mode; but this obviously will create severe limitations. Usually, you will want a -complete independant system. +complete independent system. The system for the subhurd is a normal Hurd installation, which could just as well run standalone. You can use any of the various possible installation @@ -105,9 +109,9 @@ inside the subhurd, or to `ssh` directly into the subhurd. If you want to access the subhurd processes from the outside, e.g. for [[debugging_purposes|debugging/subhurd]] (or to get rid of a subhurd that -didn't exit cleanly...), you need to find out how main Hurd PIDs correspond to +didn't exit cleanly...), you need to find out how main Hurd [[PID]]s correspond to subhurd processes: the subhurd processes appear in the main Hurd (e.g. if doing -`ps -e`) as unknown processes, and vice versa, but the PIDs are different! To +`ps -e`) as unknown processes, and vice versa, but the [[PID]]s are different! To find out which process is which, you can simply compare the order -- while the numbers are different, the order should usually match. Often it also helps to look at the number of threads (e.g. using `ps -l`), as many servers have very @@ -119,3 +123,65 @@ characteristic thread counts. Read about using a subhurd for [[debugging_purposes|debugging/subhurd]]. Roland's tutorial about [[running_a_subhurd]]. + + +# Use Cases + +<a name="debugging_main_hurd_system"></a> +## Debugging the *Main* Hurd System + +A subhurd can be used for debugging the *main* Hurd system. This works as long +as the subhurd doesn't use any services provided by the main Hurd. For +example, if you already have a subhurd running at the time it happens, you can +use that one to debug a deadlocked [[translator/ext2fs]] root file system in +the *main* Hurd. + +For this, you need to get a handle to the main Hurd's [[ext2fs +translator|translator/ext2fs]]'s [[PID]], but this is no problem, as currently +[[PID]]s are visible across subhurd boundaries. (It is a [[!taglink +open_issue_hurd]] whether this is the right thing to do in +[[open_issues/virtualization]] contexts, but that's how it currently is.) + + +<a name="unit_testing"></a> +## Unit Testing + +freenode, #hurd channel, 2011-03-06: + +From [[open_issues/unit_testing]]. + + <youpi> it could be interesting to have scripts that automatically start a + sub-hurd to do the tests + <youpi> though that'd catch sub-hurd issues :) + <foocraft> so a sub-hurd is a hurd that I can run on something that I know + works(like linux)? + <foocraft> Virtual machine I would think + <foocraft> and over a network connection it would submit results back to + the host :p + * foocraft brain damage + <youpi> sub-hurd is a bit like chroot + <youpi> except that it's more complete + <foocraft> oh okay + <youpi> i.e. almost everything gets replaced with what you want, except the + micro-kernel + <youpi> that way you can even test the exec server for instance, without + risks of damaging the host OS + <foocraft> and we know the micro-kernel works correctly, right youpi? + <youpi> well, at least it's small enough that most bugs are not there + <foocraft> 1) all tests run in subhurd 2) output results in a place in the + subhurd 3) tester in the host checks the result and pretty-prints it 4) + rinse & repeat + <youpi> the output can actually be redirected iirc + <youpi> since you give the sub-hurd a "console" + <foocraft> youpi, yup yeah, so now it's more like chroot if that's the case + <youpi> it really looks like chroot, yes + <foocraft> but again, there's this subset of tests that we need to have + that ensures that even the tester running on the subhurd is valid, and it + didn't break because of a bug in the subhurd + <tschwinge> As long as you do in-system testing, you'll always (have to) + rely on some functionality provided by the host system. + <foocraft> the worst thing that could happen with unit testing is false + results that lead someone to try to fix something that isn't broken :p + <tschwinge> Yes. + <youpi> usually one tries to repeat the test by hand in a normal + environment |