> > A better way to say it may be: if that's not what disconnect()
> > means, than what the heck _does_ it mean? There are a whole LOT
> > of answers in current use. Clearly the idea is to prohibit some
> > kinds of behavior. Which ones? And why _not_ all of them?
>
> 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.
It means that the connection between driver and interface is broken.
Nothing more, nothing less. The driver must not make further assumptions
about state or presence of the device.
Whether this is a desirable state of affairs is another question, but without
a major redisgn it cannot be changed.
Letting usbcore deal with usage after the connection is broken is
more difficult than it sounds. Reconnection is entirely legal.
Letting it deal with a physically disconnected device is easy,
but unfortunately insufficient.
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
