Re: scsi_debug in fstests and blktests (Was: Re: Fwd: [bug report][bisected] modprob -r scsi-debug take more than 3mins during blktests srp/ tests)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 21, 2022 at 10:56:57PM -0700, Christoph Hellwig wrote:
> On Thu, Apr 21, 2022 at 10:53:30AM -0700, Luis Chamberlain wrote:
> > Moving this discussion to the lists as we need to really think
> > about how testing on fstests and blktests uses scsi_debug for
> > a high confidence in baseline without false positives on failures
> > due to the inability to the remove scsi_debug module.
> > 
> > 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.

It begs the question if the same wish should apply to fstests.

If we want to *not* rely on module removal then the right thing to do I
think would be to replace module removal on these debug modules
(scsi_debug) with an API as null_blk has which uses configfs to *add* /
*remove* devices.

  Luis



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux