From mboxrd@z Thu Jan 1 00:00:00 1970 From: Douglas Gilbert Date: Thu, 18 Jan 2001 00:08:47 +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 David Brownell wrote: >=20 > There was a bit of mail last week touching on SCSI hotplugging. >=20 > 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=20 level drivers, I assumed it wouldn't be a big deal for them.=20 Both st and sg interface to applications at this level so=20 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 _______________________________________________ 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