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

[Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>]

> 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.

	Regards
		Oliver


_______________________________________________
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