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 [EMAIL PROTECTED]
