From 6ef71999bc49af76b201f36f11747148d32f5863 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 6 Mar 2011 10:52:01 +0100 Subject: Some more IRC discussion. --- hurd/subhurd.mdwn | 48 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 47 insertions(+), 1 deletion(-) (limited to 'hurd/subhurd.mdwn') diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index cb4a40a8..b8e595d3 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -21,6 +21,8 @@ possible to use [[debugging/gdb/noninvasive_debugging]], but this is less 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 @@ -139,3 +141,47 @@ 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.) + + + +## Unit Testing + +freenode, #hurd channel, 2011-03-06: + +From [[open_issues/unit_testing]]. + + it could be interesting to have scripts that automatically start a + sub-hurd to do the tests + though that'd catch sub-hurd issues :) + so a sub-hurd is a hurd that I can run on something that I know + works(like linux)? + Virtual machine I would think + and over a network connection it would submit results back to + the host :p + * foocraft brain damage + sub-hurd is a bit like chroot + except that it's more complete + oh okay + i.e. almost everything gets replaced with what you want, except the + micro-kernel + that way you can even test the exec server for instance, without + risks of damaging the host OS + and we know the micro-kernel works correctly, right youpi? + well, at least it's small enough that most bugs are not there + 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 + the output can actually be redirected iirc + since you give the sub-hurd a "console" + youpi, yup yeah, so now it's more like chroot if that's the case + it really looks like chroot, yes + 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 + As long as you do in-system testing, you'll always (have to) + rely on some functionality provided by the host system. + 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 + Yes. + usually one tries to repeat the test by hand in a normal + environment -- cgit v1.2.3