From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Date: Thu, 18 Jan 2001 09:03:44 +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="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > 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