Re: SCSI Patches - mostly on/off-line stuff

["Eric Youngdale" <eric@andante.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" <dougg@torque.net>
To: "David Brownell" <david-b@pacbell.net>
Cc: <linux-scsi@vger.kernel.org>;
<linux-hotplug-devel@lists.sourceforge.net>
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úLSE 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