On Mon, Oct 22, 2018 at 04:08:30PM -0700, Omar Sandoval wrote: > On Mon, Oct 22, 2018 at 06:50:04AM -0400, Theodore Ts'o wrote: > > A number of kernel modules used by blktests must be compiled as > > modules, since the module needs to be loaded with specific options, or > > part of the test is to exercise what what happens when the kernel > > module is loaded. This is not true for the loop driver, so add a new > > bash function, _have_kernel_module which works like _have_module but > > will not fail if the driver is compiled directly into the kernel. > > `modprobe loop` works for me if the module is built in, are you using > one from busybox or something? According to strace, it looks at the > depmod information (namely, /lib/modules/$(uname -r)/modules.builtin.bin). Ah, you're right. When I was first trying to use blktests, I was integrating it into my xfstests test appliance, and normally I build a completely module-free kernel. This allows me to boot directly into a kernel by using kvm's "--kernel /path/to/bzImage" option without having to deal with the extra work of trying to install modules into a test appliance. So when I noticed that modprobe loop wasn't working, this was because I didn't have any of /lib/modules/($uname -r)/ in existence at all. After I patched blktests to not complain when modprobe loop was failing, I noticed that something like only 3 tests were being run, and when I looked at most of the tests, I realized that there was no way to avoid using modules for a large number of tests (at least not without doing a lot of work to enhance things like scsi_debug to be dynamically reconfigurable). So you're right; there's no need for this patch. The chances that someone will only want to run the loop tests using !CONFIG_MODULES kernel are... remote. :-) - Ted
