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

[Miles Lane <miles@megapathdsl.net>]

Oliver Neukum wrote:
> 
> > 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?
> 
> There are hotplugging devices out there.
> Some basic solution is needed.
> 
> > 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 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,
> 
> For device addition at least that is always the case.
> One problem less.
> 
> > 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)
> 
> Device removal seems to be the hard case.
> 
> How about the following solution:
> 
> 1. A flag to mark the device hotpluggable, like the emulated flag
> 2. export the add/remove-device call
> 3. return proper error codes for the unregister calls (and the calls from 2.)
> 4. add a call for taking the device offline
> 
> IMO we are now at a stage where the number of open fds cannot increase, can
> it ?
> 
> 5. add a status of catastrophic failure to the returnable states -> no error
> handling, get the device offline
> 
> Now we have solved the problem of how to deal with "in flight" commands.
> To the upper layers unplugging is like a dreadful error whch they have to
> handle anyway.
> 
> 6. add a callback (w. a private data pointer) to be called when the usage
> count drops to zero. At this time removal must work and low level drivers can
> free memory.
> 
> This scheme is not the most elegant as it leaves the issues of replugging
> with the low level drivers, but it is implementable without great changes.

I'd be delighted to see an ongoing exploration of what is necessary and 
feasible for the 2.4.0 series kernel (this message is a good start of
that topic), plus what ought to be undertaken in 2.5.0 in order to
create 
thorough and clean hotplugging support.  Hopefully, some work will be 
shared.  We'd probably do the shared stuff first and then branch off
into 
the deeper and more dangerous work.

	Miles

_______________________________________________
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