> > It means that the device is physically gone, that's it. What the driver
> > wants to do with this information is up to it. But the core has to
> > handle attempts to use this device after it is gone, like it now does.
>
> That's an interesting model, but it doesn't seem to handle some
> current usage correctly. Notably rmmod (yes, in flux, and many
Right. It fails for those cases where usbcore doesn't know whom
the call comes from, things like usb_reset_device() and usb_clear_halt().
Any API function would have to take an interface as argument,
so that usbcore can check for logical disconnection.
As for module unload, may a holder of a reference go away? That is,
mustn't functions that raise usage count of a data structure raise the module
usage count of the module holding a reference ?
> layers of things could yet be changed then re-stabilized) and
> other cases where the driver would be disconnected while the
> device is still present. Drivers would still need to release
> locks when the hardware is gone; maybe they can just deduce that
> it's time to do that by looking for particular status codes.
> Interesting because of the questions it suggests: since that view
> makes disconnect() into nothing more than a hint, why not just remove
> that disconnect method entirely? What _other_ things would need to
> change if usbcore stopped even providing that hint?
Things like open(), that need to fail after disconnect(), could not fail.
Devfs would no longer work.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
