Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58

[David Brownell <david-b@pacbell.net>]

Luben Tuikov wrote:
> 
> When the Low Level Device Driver (LLDD), being the transport portal,
> notices that the device is going away or has gone away from the
> ``fabric'' (wlg), it will fire a device-gone event with the kernel.
> *Not* necessarily with SCSI Core, in fact I'd rather it didn't,
> but with a well defined kernel entry for device-gone events.
> 
> At the same time the LLDD will start returning TARGET gone, or
> whatever is appropriate to newly queued commands, and error out
> all internally queued commands (if it does it's own queuing).
> (I've seen this work nicely on mount and read/write(2) and fsck.)
> 
> I.e. the ``synchronization'' has started already by the LLDD erroring
> out commands, new and queued.

This model I like, though FWIW the USB code has pretty messy
handling of the (a) cancel queued requests and (b) reject new
requests parts of that model.  All the updates to handle that
would be transparent to device drivers (other than HCDs); we've
discussed it a bit.


> All the while the kernel has started higher level cleaning up,
> decrementing ref counts, etc, 

... Invoking some hotplug event that might unmount filesystems,
so _all_ relevant kernel state can be cleaned up ...


> But there's no such thing as ``waiting around indefinitely'' or
> ``blocking wait'' as you've suggested in some of your emails.

Right.  Though I can wish the driver model core actually used
its "enum device_state" and had an instance variable of that
type in "struct device".  That'd help the bus level driver
(for SCSI, an LLDD or LLD; for USB, an HCD) with (a) and (b).

The "no waiting indefinitely" is in part that because knowing
both (a) and (b) happen means you know the device quiesces.

- Dave