Re: [PATCH blktests] common/rc: allow the loop driver to be built into the kernel

["Theodore Y. Ts'o" <tytso@mit.edu>]

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