Resetting a hub also resets devices on downstream ports ...
including the DVD you may have been burning!   ...

I'm not sure how often that special case code has been used;
I don't recall noticing it happen  (Maybe that's because
it's reporting with KERN_DEBUG.  It should use dev_err.)


Maybe it never has happened.  Not having had much experience with them, I
would imagine that hubs are usually pretty reliable.

Not necessily; unpowered ones often make trouble.



Why would you say hubs should act that way?  It'd make sense
to me for hubs to be like usb-storage, and support a limited
amount of history during resets.  Enough to do a more graceful
restart for devices that have significant driver state (like
the SCSI stack, which can show as files in a user's GUI).


A hub doesn't have any state that it needs to preserve across a reset, or
at least none that can't be reconstructed after the reset.  Since the
reset will automatically disconnect all downstream devices, we not only
don't want to save the current state, we want to get rid of the state as
easily as possible!

But "easily" for who? Every user visible function associated with that state would flicker out of existence, then come back ... and it's a lot more typical that it come back as "something else" in that case. Even when it's clearly the same device, by all relevant metrics.

Easily for developers -- sure, let's have resume processing that
always destroys (then recreates) devices.  We know that'll be a
rich vein of bugs to mine, many of which will be worth fixing.

Easily for users ... that'd mean smarter resume processing, which
avoids mining those particular bugs unless it's unavoidable.

- Dave





-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to