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 ++++++++++++++++++++++++- open_issues/perlmagick.mdwn | 45 ++++++++++++++++++++++- open_issues/unit_testing.mdwn | 83 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 174 insertions(+), 2 deletions(-) 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 diff --git a/open_issues/perlmagick.mdwn b/open_issues/perlmagick.mdwn index 1daac62b..8a57a8fd 100644 --- a/open_issues/perlmagick.mdwn +++ b/open_issues/perlmagick.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 @@ -57,6 +57,49 @@ Etc. +/usr/lib/gcc/i486-gnu/4.4.2/include/omp.h: +# State as of 2011-03-06 + +freenode, #hurd channel, 2011-03-06: + + tschwinge: (speaking on working perl, how did it en with that + "(glibc) double free" crash with perl?) + *end + I think I remember I suspected it's a libgomp (!) issue in the + end. I have not yet continued working on that. + libogmp? looks like you know more than me, then :) + tschwinge: oh, I'm interested + I know a bit about libgomp :) + I bisected this down to where Imagemagick added -fgomp (or + whatever it is). And then the perl library (Imagemagick.pm?) which loads + the imagemagick.so segfaulted. + ImageMagick did this change in the middle of a x.x.x.something + release.. + My next step would have been to test whether libgomp works at + all for us. + ./usr/sbin/debootstrap:DEBOOTSTRAP_CHECKSUM_FIELD="SHA$SHA_SIZE" + erf + so they switched to another checksum + but we don't have that one on all of our packages :) + tschwinge: + buildd@bach:~$ OMP_NUM_THREADS=2 ./test + I'm 0x1 + I'm 0x3 + libgomp works at least a bit + OK. + i guess we should hope the working bits don't stop at that point + ;) + If open_issues/perlmagick is to be believed a diff of 6.4.1-1 + and 6.4.1-2 should tell what exactly was changed. + Oh! + I even have it on the page already! ;-) + -fopenmp + I've tried the pragmas that imagemagick uses + they work + Might be the issue fixed itself? + I don't know, it's the latest libc here + (and latest hurd, to be uploaded) + + # Other [[!debbug 551017]] diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn index 0ff7ecca..a5ffe19d 100644 --- a/open_issues/unit_testing.mdwn +++ b/open_issues/unit_testing.mdwn @@ -58,6 +58,8 @@ abandoned). Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt, 2010-10-28. [v2](http://lwn.net/Articles/414064/), 2010-11-08. + * + # Related @@ -237,3 +239,84 @@ EPERM](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00007.html) wasn't it already in the gsoc proposal? bummer nope + +freenode, #hurd channel, 2011-03-06: + + how's the hurd coding workflow, typically? + +*nixness* -> *foocraft*. + + we're discussing how TDD can work with Hurd (or general kernel + development) on #osdev + so what I wanted to know, since I haven't dealt much with GNU + Hurd, is how do you guys go about coding, in this case + Our current workflow scheme is... well... is... + Someone wants to work on something, or spots a bug, then works + on it, submits a patch, and 0 to 10 years later it is applied. + Roughly. + hmm so there's no indicator of whether things broke with that + patch + and how low do you think we can get with tests? A friend of mine + was telling me that with kernel dev, you really don't know whether, for + instance, the stack even exists, and a lot of things that I, as a + programmer, can assume while writing code break when it comes to writing + kernel code + Autotest seems promising + +See autotest link given above. + + but in any case, coming up with the testing framework that + doesn't break when the OS itself breaks is hard, it seems + not sure if autotest isolates the mistakes in the os from + finding their way in the validity of the tests themselves + it could be interesting to have scripts that automatically start a + sub-hurd to do the tests + +[[hurd/subhurd#unit_testing]]. + + foocraft: To answer one of your earlier questions: you can do + really low-level testing. Like testing Mach's message passing. A + million times. The questions is whether that makes sense. And / or if + it makes sense to do that as part of a unit testing framework. Or rather + do such things manually once you suspect an error somewhere. + The reason for the latter may be that Mach IPC is already + heavily tested during normal system operation. + And yet, there still may be (there are, surely) bugs. + But I guess that you have to stop at some (arbitrary?) level. + so we'd assume it works, and test from there + Otherwise you'd be implementing the exact counter-part of what + you're testing. + Which may be what you want, or may be not. Or it may just not + be feasible. + maybe the testing framework should have dependencies + which we can automate using make, and phony targets that run + tests + so everyone writes a test suite and says that it depends on A + and B working correctly + then it'd go try to run the tests for A etc. + Hmm, isn't that -- on a high level -- have you have by + different packages? For example, the perl testsuite depends (inherently) + on glibc working properly. A perl program's testsuite depends on perl + working properly. + yeah, but afaik, the ordering is done by hand + +freenode, #hurd channel, 2011-03-07: + + actually, I think for most tests it would be better not to use a + subhurd... that leads precisely to the problem that if something is + broken, you might have a hard time running the tests at all :-) + foocraft: most of the Hurd code isn't really low-level. you can + use normal debugging and testing methods + gnumach of course *does* have some low-level stuff, so if you add + unit tests to gnumach too, you might run into issues :-) + tschwinge: I think testing IPC is a good thing. as I already said, + automated testing is *not* to discover existing but unknown bugs, but to + prevent new ones creeping in, and tracking progress on known bugs + tschwinge: I think you are confusing unit testing and regression + testing. http://www.bddebian.com/~hurd-web/open_issues/unit_testing/ + talks about unit testing, but a lot (most?) of it is actually about + regression tests... + antrik: That may certainly be -- I'm not at all an expert in + this, and just generally though that some sort of automated testing is + needed, and thus started collecting ideas. + antrik: You're of course invited to fix that. -- cgit v1.2.3