> > Drivers are never the first to increment a count, or last to decrement.
> > (Unless they've got significant bugs...)
>
> Today this is a requirement for drivers, but only because of the way the
> current code works.
Seems almost tautological ... :) You want to change those requirements.
I'm still curious exactly what you'd change them to be ... what change are
you proposing for disconnect() behavior, for example? How exactly would
this new driver-visible "zombie device" state work? When you start that
work you mentioned, I'll be interested in the answers.
> For only one simple example of why it might be nice for drivers to be
> able to drop the last reference to a usb device, take a look at the
> visor driver. close() ends up getting called right after disconnect()
> happens for a wide range of devices. We go through some pretty good
> race condition handling to properly deal with this. If a usb device
> could be "used" even if the device is not present, drivers have a much
> easier time of things. Which is a good thing :)
(I'd have to do more than just "look" at visor... it's written to a layer
above USB! :)
For a while I went down that path, of trying to behave reasonably
in the face of many of the errors that would happen if devices
had such a zombie state. Not very successfully; too many places
expect most of the "full state" will be usable. That's why I asked
how much device functionality you expected would be available.
("None" is the answer I eventually settled on: no such state.)
It's as least as good a thing to keep complexity out of code by
sticking to simple requirements ... like "when you return from
disconnect, that means you're not using the device any more." :)
While I think this next bit of stuff is interesting/important, it seems
very much a separate set of issues:
> Also, if we have this, the logic to handle when a device is
> disconnected, and the driver wants to keep the userspace handle open,
> dropping data on the floor, until the device is reconnected, is much
> easier. I've heard talk that the network people want this for their USB
> devices, and I know there are usb-serial customers who almost demand
> this functionality.
That demands some notion of device identity, and not all devices
support one. Short of that, we need "stable" physical IDs (wrapping
routing info like adapter addresses and hub port routes) so drivers
can apply logic like "if it's the same physical ID and device descriptor,
assume it's the same real device". (Similar to "same serial number
and device descriptor..." but more sensitive to devices moving, in
the general case where there's more than one of each device type.)
While I absolutely agree that we need to enable that kind of behavior,
I think it's best keyed by a kind of logical device identity, using whatever
is appropriate for the driver (serial numbers? physical port routing?
authentication by cryptographic challenge? something else?) rather
than by a "struct usb_device *" handle ... that kind of identity isn't
something that the core of USB (or any interconnect technology)
should be handling. Easily layered though.
My next patch (looks like it won't be today :) addresses the "physical ID"
side of that problem. We're most of the way there, it's pretty simple now
in fact but it involves moving a field from one structure to another, so the
patch looks big.
- Dave
Sponsored by http://www.ThinkGeek.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
