scsi_debug 1.64 , remove detect(), "hotplug" hosts

This patch is against lk 2.5.46-bk3 which includes Christoph's work removing the requirement for detect() functions in LLDDs. He sent me an example for scsi_debug which I have built on with this patch.

As threatened, this version includes a "scsi_debug_add_host" parameter. At kernel or module load time this is an absolute number (0..127 are allowable and 1 is the default). So:
modprobe scsi_debug scsi_debug_num_devs=20 scsi_debug_add_host=0
will result in no scsi_debug hosts (thus no devices) but the driver has 20 slots available for devices.

Then a host can be introduced (simulated hotplug) by
echo 1 > /sysfs/bus/scsi/drivers/scsi_debug/add_host
This causes a scsi_debug host to appear and devices get found on it [14 in my system: 7 targets (0..6) each with 2 luns (0..1)]. Another host hotplug can be simulated by
echo 1 > /sysfs/bus/scsi/drivers/scsi_debug/add_host
which results in another 6 devices being attached (for a total of 20 scsi_debug devices as dictated by the original scsi_debug_num_devs).

That last (second) scsi_debug host can be removed by
echo -1 > /sysfs/bus/scsi/drivers/scsi_debug/add_host
and its 6 devices go. Another application of this "echo" removes the first host and all remaining devices.

Seems to work fine.

Notes:
- Christoph and Mike A. are pulling me in 2 different directions. In this case Christoph got to me first so I have moved along that direction. Mike's "/sysfs/bus/scsi_dbg_fake" has me perplexed ...
- rmmod and subsequent modprobe's on scsi_debug sometimes blow up.
Hopefully Patrick's fix (not in bk3?) addresses that.
- this patch has a work around for a kernel sscanf() bug (parsing -ve numbers). Randy Dunlap has attended to that.
- the simulated "hotplug" thread belongs to the echo command or some sysfs magic. scsi_debug could schedule a timer event and do the hotplug (hot unplug) in the context of a timer interrupt (?) for added reality.
- cleaned out some extraneous includes and comments. Suggestions welcome.

Doug Gilbert

I was not trying to pull in another direction, but my patches may have had to many steps in one chunk that may have made it look that way.

I have split the functionality of my previous patch for scsi_debug into smaller chunks. I believe there are advantages to scsi mid code and the device model code in making scsi_debug look more like a real adapter.

I need to do more testing hopefully I can send you something Sunday if you are interested.

I would use the changes that Patrick sent out as we had problems with insmod / rmmod without these. I previously sent these to Mochel, but he was in the process of moving and they probably will not show up in a bk ( or fixes like these) until he can respond.

It seemed when I was re-working my patches that num_hosts_present is used during scsi_debug_exit to cleanup, but is not incremented during sdebug_add_host_write. There seems to a mixed use of scsi_debug_add_host and num_hosts_present.

-andmike
--
Michael Anderson
[email protected]

<snip/>

Mike,
I have cleaned up that problem and a new version of scsi_debug 1.64 is attached (applies against 2.5.46-bk3 (or the last version of 1.63 that I sent a week ago)).
The second attachment is the changes to scsi_debug.c since the start of this thread.

This version has been tested against a kernel with Patrick's two patches for modprobe/rmmod stability that were sent to this list last week. [One modifies sysfs source and the other changes scsi_scan.c] In this environment I tried about 20 or more sequences of modprobe/rmmod on scsi_debug without problems. Also using scsi_debug_add_host to add and remove hosts caused no problems.

Doug Gilbert