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

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

Luben Tuikov wrote:

> David, when I said ``... the transport will tell the LLDD that the
> device ...'' this is *exactly* what I meant.  You're just repeating
> it here in a more broken-down way.

OK


> By transport I mean USB, FC, SPI, etc; LLDD is the transport portal
> and the initiator (aka the initiator port).  This terminology is not
> really that new, but still not that old, and described in SAM-3.

I was hoping for something described in the 2.5.58 kernel docs,
which only talks about LLD (Documentation/scsi) except in one case
(looked like a typo) ... I remember SAM-3 as a kind of missile!



> We just cannot let a transport event just wipe out a device,
> without consulting hotplugging first -- think security.

Certainly "device gone" would be an auditable event, but this is
primarily an integrity issue:  don't free objects until other
components have stopped using them.

If any components attach security policies to that "gone" state
transition, that'd be atypical but purely their own business.
(Like a transport erasing session master keys ... most transports
wouldn't have them, and would likely erase them as soon as the
device is known to be gone, no hotplug involved.)


> That is, when a transport event takes place, the LLDD doesn't
> have to ``run to'' SCSI Core right away. Just let the kernel
> know about this event, and start returning errors, on newly
> queued commands.
> 
> The kernel will decide what to do about this device going away,
> i.e. hotplugging, sysop notification, etc.

Sounds right. Except that it'd normally be the SCSI core that
we "let" know about the event. (Not always, I can imagine that
some transports might be able to kick in recovery procedures
and find some other path for accessing the device.  But in
such cases, SCSI might never see the device as "gone" ... )

- Dave