> > 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!
Possibly the view people at IBM have of SCSI is more comprehensive
than ordinarily used. We are probably better of talking about low
level drivers (LLDs). Whether these drive devices, busses or
transport mechanisms is not really relevant here.
> > 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.
Right. There's nothing wrong with a LLD having to wait for
a _limited_ time by making a blocking call to the midlayer.
But that call must finish within a limited,reasonable time and it must
succeed. The complexity for handling hotunplugging belongs
squarely in a centralised place, but not every LLD.
It is true that currently hotplugging is a generic safety problem
(unless you use devfs).
The problem is reuse of device nodes leading to a race with
the hotplug skripts. Old permissions may for a time be applied
to a new device. But that just means that the hotplugging
user space notification model is incomplete. Now the simple fix with
a callback into the LLD which would allow simply waiting for the
unplugging skript to run is true madness. You cannot stall a hotpluggable
subsystem waiting on a skript, neither can you do sane error handling.
Problem should be fixed where they arise, eg. "lock" a new hotplugged
device.
> 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.)
Right.
> > 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" ... )
I must disagree. There's no decision involved here. You handle
tasks having the device open, clean things up, free up the resources
and fire off a user space notification.
Decisions get made in user space where policy can be reasonably
implemented.
Regards
Oliver
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
