Re: [PATCH] scsi_set_host_offline (resend)

[Luben Tuikov <tluben@rogers.com>]

Oliver Neukum wrote:
> 
> Please explain yourself further. We cannot deal with wait sometimes.

No need to -- we agree.

> Either we may wait or we may not wait. If we may wait,
> we must always deal with it like we will wait and deal with results,
> which is impossible, as the only result we can deal with is success.
> 
> Notification is absolutely no problem. _Requiring_ the kernel
> to wait for user space to act so that the process of removal
> can be completed as far as the the low level driver is concerned
> is a major problem.

No, a LLDD will not be required to wait on userspace.  No one wants
this and the fault in this is quite evident that no one would want it.

The only point is notification, and we seem to agree on this.
 
> All is well if a low level driver can consider a device gone for good
> as soon as "/sbin/hotplug" is spawned. The key here is spawned
> , not doing something or finish, but spawned.

Ideally:

You can assume even better than that: as soon as your interconnect
tells you that the device is gone, a LLDD (= transport portal) does this:
---> calls xxx_dev_removal(dev) (marks device as gone in this subsystem),
(and which in turn:
  ---> calls scsi_device_removal(dev) (mark dev as gone in this subsys),
    ... (see my other posting))
(none of which blocks, more work/discussion is needed here, but this is
different topic)

and then the LLDD can free *its* resources which it allocated on the
device.

*But*, the _important__point_ is that the LLDD must be able to handle
requests (queuecommand()) to non-existant (= just removed) devices,
and not oops, or whatever.

So, in effect, you just call usb_dev_removal(dev) (to be written),
and free _your_ resources on the device. (note important point above)

> We have indeed discussed this before and the need to notify
> user space was never questioned, as far as I recall.
> The point of contention always was whether the notification
> had to do specific things for the process of unplugging to finish
> as far as it concerns the low level driver.

Right.  As far as I can see, those subsystem entries, xxx_dev_removal(dev),
would do things which do not block, like flip a bit, flags, integer,
wake up a thread, etc, call the above subsystem's xxx_dev_removal(dev),
and return immediately. (as per my other posting)
(this needs more thinking though)

-- 
Luben




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel