On Thu, Apr 21, 2022 at 10:56:57PM -0700, Christoph Hellwig wrote:
> > This should also apply to other test debug modules like null_blk,
> > nvme target loop drivers, etc, it's all the same long term. But yeah
> > scsi surely make this... painful today. In any case hopefully folks
> > with other test debug drivesr are running tests to ensure you can
> > always rmmod these modules regardless of what is happening.
>
> Maybe fix blktests to not rely on module removal I have such a hard
> time actually using blktests because it is suck a f^^Y% broken piece
> of crap that assumes everything is modular. Stop making that whole
> assumption and work fine with built-in driver as a first step. Then
> start worrying about module removal.
I would love it if blktests didn't require modules, period. That's
because it's super-convenient to be able to pluck a kernel out from
the build tree without having to install it first. If all of the
necessary devices could be built-into the kernel, this would allow
this to work:
make
kvm-xfstests --blktests
which ends up running something like this:
/usr/bin/kvm -boot order=c -net none -machine type=pc,accel=kvm:tcg \
... \
--kernel /build/ext4/arch/x86/boot/bzImage
--append "quiet loglevel=0 root=/dev/vda console=ttyS0,115200 nokaslr fstestopt=blktests,aex ..."
Unfortunately, because blktests requires modules, I can only do this
sort of thing using gce-xfstests and by passing in a kernel.deb file
so I can get the !@#@! modules installed. (If I could use kexec with
gce-xfstets, I'd shave almost a minute of test appliance setup time,
and starting a GCE VM talks a minute or two extra over using
kvm-xfstests.)
I think we would need to make some changes to how scsi_debug and other
block device modules, first, though. blktests is using modules
because that appears to be the only way to configure some of these
test/debug drivers and then have the debug device show up with the
specified characteristics.
- Ted
