From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Youngdale" Date: Thu, 18 Jan 2001 15:37:16 +0000 Subject: Re: SCSI Patches - mostly on/off-line stuff Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org As far as the mid-layer is concerned, hotplugging more or less consists of two independent tasks. Addition of new devices, and removal of devices. To support addition, the main question is how one detects that a device has been hotplugged in the first place, and whether this detection mechanism tells you what devices are new, or whether a new bus scan needs to be initiated. In the event that the low-level driver has some way of being notified that a new device is on the bus (along with the ID and LUN) then it would mainly be a matter of exposing the appropriate interfaces to low-level drivers so that they can register the detection of new device. In the event that a bus scan would need to be re-initiated, then a little more thought would have to go into it, I suppose. The tricky bit here is going to be the question of what context these functions would be called - the functions for adding devices really weren't designed for the purposes of being called from an interrupt context, for example. The question of hotunplugging a device is a bit trickier as there are potential race conditions in the event that the device is in use. Currently as things stand, removal of a device fails if the device is busy (i.e. has open file descriptors) - note that there may be a small window of a race condition between the open() function where we increment the usage count and the device removal, but with a minor amount of work this could be fixed. Perhaps a better question to examine is whether our device removal strategies needs to be improved. It would be quite possible of course to fix things so that even if there are open file descriptors and a device is removed that it would still work. I am thinking of a flag of some sort that would say "delete when usage count drops to 0" or some such - not hard to implement either, and would be a bit more robust than what we have now. Sort of a "pending remove" of the device. This sort of thing is not all that compatible with the modules code - I believe that module removal can either succeed or fail, but there is no "pending removal" state of a module. Anyways, my initial question reallly has to do with exactly how one is notified that a new device has appeared and whether a bus scan needs to be initiated or not. That will control the degree to which we have to screw with things in the mid-layer to support this. -Eric ----- Original Message ----- From: "Douglas Gilbert" To: "David Brownell" Cc: ; Sent: Wednesday, January 17, 2001 7:08 PM Subject: Re: SCSI Patches - mostly on/off-line stuff > David Brownell wrote: > > > > There was a bit of mail last week touching on SCSI hotplugging. > > > > I'd be interested in knowing if there's any sort of "status quo" > > or "plan of record" there. Or even a list of open issues, > > given that I understand there's a lot of interest in fitting > > SCSI and hotplugging together! > > The basic question is whether hot-plugging support is > just too much effort for the lk 2.4 scsi subsystem and > should be left to lk 2.5? OTOH could there be a series > of incremental changes in lk 2.4 to support it? > > The areas of interest are: > 1) lower level (pseudo) drivers [e.g. usb/storage + sbp2_1395] > 2) scsi mid level > 3) scsi upper level drivers [sd, sr, st + sg] > 4) block + cdrom subsystems > > In area 1) the driver authors are keen to get things going. > Various approaches have been tried: > - user intervention via rescan-scsi-bus.sh script [found in > recent Suse distros in the scsi.spm package] > - scsi_(un)register_host() > - [perhaps online=FALSE for temporary outage] > > In area 2) we usually defer to Eric Youngdale on design > issues. The add/remove-single-device procfs technique (as > used by rescan-scsi-bus) is only allowed when the device > has no open fds. To remove the user intervention requirement, > exported C calls equivalent to add/remove-single-device need > to be added (or existing calls stretched). As for allowing > those calls when there are open fds, there are issues: > a) command "in flight" or could be in error recovery > b) re-entrancy? > c) mid level resource control (e.g. Scsi_Device objects) > d) impact on areas 3) and 4) > > In area 3) my last post pointed out that, at least from > the sg driver's point of view, it would not be that difficult. > Coping with a premature sg_detach() isn't that much different > from coping with a premature sg_release() which it already > does. Extending from my own narrow area to the other upper > level drivers, I assumed it wouldn't be a big deal for them. > Both st and sg interface to applications at this level so > this is the end of their story. > > In area 4) the sd and sr drivers interface to the block and > cdrom subsystems. Maybe others could comment on the impact here. > > Doug Gilbert > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@vger.kernel.org > _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel