Hi Dan, On Thu, Feb 23, 2012 at 10:35 AM, Dan McGee <dan@xxxxxxxxxxxxx> wrote: > On Thu, Feb 23, 2012 at 5:52 AM, Lucas De Marchi > <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >> Hi Dan, >> >> On Thu, Feb 23, 2012 at 3:59 AM, Dan McGee <dan@xxxxxxxxxxxxx> wrote: >>> On Wed, Feb 22, 2012 at 11:56 PM, Dan McGee <dan@xxxxxxxxxxxxx> wrote: >>>> The current configuration is dumb in any number of ways: >>>> 1) If the rationale was for space savings, it works the opposite- the >>>> git repo gets more bloated because we are adding binary compressed >>>> blobs that share little in common with their parent, and anyone that >>>> wants to run the test suite has to unzip it anyway. >>>> 2) It is a pain in the butt to add new tests, and not accidentally lose >>>> any new rootfs you built in the directory. >>>> 3) `git status` won't help you if you are tweaking files in the rootfs >>>> and don't know they have been changed, or if some test did that and >>>> you couldn't detect it. >>>> 4) `git log` won't help you find out what is changing in the rootfs test >>>> directory itself when changes are made to the binary blob, such as >>>> new files being added or even existing files being tweaked. >>>> 5) The files just aren't that big anyway- 2.7MB unzipped. >> >> >> How do you handle the case in which a file needs to be deleted in the >> rootfs? E.g: >> >> ./testsuite/test-foo >> -> it deletes testsuite/rootfs/foo/sys/module/asdf/initstate >> ./testsuite/test-foo >> -> test fails because it assumes module was not loaded >> >> You can't call "git checkout" because you need to run testsuite with >> the distributed tarball. > > Is this an actual situation, or are you just trying to play devil's > advocate here? I don't see any current tests that work like this. It's listed as a FIXME since I added the testsuite: $ grep FIXME testsuite/delete_module.c * FIXME: change /sys/module/<modname> to fake-remove a module Dave (falconindy) was working on this last week because we are needing a test that depends on it (dependency loops in install commands that rely on the fact that a module was previously inserted in order to work nonetheless the loop exists) > Additionally, your current make rules don't accommodate this; if the > "testsuite/rootfs" directory exists at all, it doesn't get > re-extracted. Also, depending on the tests running in a certain order That's because we didn't need it yet. However adding the test for the install commands is very much needed since this is and easy thing to break on future releases (we already had this regression twice in kmod). > with side effects breaks parallel make. No, we don't depend on them running in a certain order. We only need to make sure the rootfs is extracted before any test - this would be accomplished by autofoo > > Rather than a file getting deleted; the file should be created only > for the test that needs it, and then removed after (and also ensure it > is removed for any test that would fail if it exists). Alternately, > the environment should be copied to a temp directory and modified > accordingly before running the test. Finally, you could just take the > easy way out, and add a new directory under testsuite/rootfs with the > altered environment. The last approach is the only sane one. This would cope with both my concerns and yours. 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