On Fri, Feb 3, 2012 at 3:37 PM, Dan McGee <dan@xxxxxxxxxxxxx> wrote: > On Fri, Feb 3, 2012 at 11:30 AM, Lucas De Marchi > <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >> Hi Dan, >> >> On Fri, Feb 3, 2012 at 3:23 PM, Dan McGee <dan@xxxxxxxxxxxxx> wrote: >>> Apparantly my previous patch is in error, as: >>> 1) test/ isn't even used anymore, but it is still present in git for who >>> knows what reason, and >> >> Reason is that testsuite was merged recently. All tests should migrate >> to testsuite so we can test all of them with testsuite. I added some, >> fixed bugs, added more, but there are still pending tests on test dir. >> >> Instead of just deleting all files at once, lets delete them once they >> are migrated to testsuite? >> >> Could you help migrating them? > > If I have time (which I don't right now). > > I was simply wondering why `make check` wasn't working in my kmod git > checkout and came across this. It looks like the make rules have > already been removed for test/ (not to mention the .gitignore rules > were dropped in your "testsuite: add skeleton" commit, 80f9e02382). > This lead me and probably others to believe test/ was not being used > whatsoever- nothing is ever built in that directory anymore. Yeah, that's right. Files in test/ dir are only waiting for their death penalty. They are not built anymore. > > Can you please outline what the difference between test/ and > testsuite/ is, and why migration entails? There is no test was a dir to put simple programs to check libkmod's API. Since two weeks ago we added testsuite/. This includes a test framework for automated tests (testsuite.c and testsuite.h) and some tests. This was needed because we don't want to touch user's system configuration in order to run tests and we want to run all of them in all architectures with all the weird configs people are using out there (yes, I'm looking to you alsa-utils). So we had to provide a way to: 1) Fake calls related to paths (we don't want to mess with /etc/modprobe.d/, /lib/modules) 2) Fake calls to init_module() and delete_module(): we don't want to really go to the kernel: it's sufficient to just have a way to fake the return codes 3) Fake calls to uname() 4) Isolate tests: each test runs in a separate process, can have their own rootfs, their set of configurations, indexes, etc, etc 5) We want to be able to test modprobe/insmod/rmmod tools and not only the library APIs. Running isolated tests as detailed in (4) we can fork and exec our test. And testsuite has support for comparing the expected stdout/stderr. We achieve 1, 2 and 3 by LD_PRELOAD'ing some libs that we compile during make check (path.so, init_module.so, delete_module.so, uname.so) > testsuite/README, or really any documentation on how to write or run > the tests at all (other than guessing the standard `make check` would > run them). Yeah... a README for the testsuite is needed. But the best thing to do is just to copy and paste from existing tests. We have examples running modinfo, modprobe and simple ones only calling the library functions. That said... I do plan to add a README file there when time allows. Hope this explanation clarifies testsuite a little bit. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
