Am Dienstag, 6. Januar 2004 16:59 schrieben Sie:
> Oliver, I like your messages. You always make me stop and think again. :-)
>
> When starting this thread, I had in mind some fairly small changes that
> would easily go into the 2.6 kernel series. But the kind of thing you and
> David are suggesting would be much larger, affecting most of the USB
> drivers. It should wait for 2.7.
Just wait what David and I have been discussing for 2.7 :-)
But what we have discussed so far affects only the hub driver and resetting.
Resetting is broken anyway.
> On Tue, 6 Jan 2004, Oliver Neukum wrote:
>
> > Am Dienstag, 6. Januar 2004 00:06 schrieb Alan Stern:
> > > 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!
> >
> > Not true for the downstream devices.
>
> I meant that in 2.6 we should get rid of the state. You are saying that
> once we institute this big change, in 2.7, the hub driver will want to
> maintain the port states during a reset so that downstream devices can be
> reconnected with their drivers properly. I agree.
Good.
[..]
> > On the contrary. I think you have solved the reentrancy due to reset problem.
> > It requires two new hooks, though.
>
> The hooks themselves are trivial; it's what the device drivers will do
> with them that's hard! The driver has to know what to do about incoming
> requests while the device is unavailable, it has to be prepared to find
> that the device ends up disconnected instead of reappearing later, and it
> has to be ready to reinitialize the device if/when it does reappear.
Nothing of this is a new requirement. Treat the new hooks like disconnect
and a subspecies of probe and you arrive at the current behaviour. The only
drivers required to implement them would be those using usb_reset_device()
from probe().
Having to wait on IO because a device is not ready is hardly a new
requirement. Neither is dealing with IO failing due to device removal.
They work by allowing drivers to keep state across reset, they don't require
it.
> Then there's the assumption that while the reset was in progress, nobody
> monkeyed around with the USB cables, unplugging one device and plugging
> another in its place...
For the first implementation we can ignore that issue. Long term it can be
dealt with by allowing "reinit()" to fail.
> > [..]
> > > > > This would permit an attractive concurrency in handling unplug events.
> >
> > Concurrency is not attractive, unless performance is an issue.
> > It is just a source of problems. If something goes wrong in kernel space
> > you are heading for reboot. It is just a matter of time.
>
> I disagree with part of that. Concurrency is useful for partitioning
> problems, as least for a while. Right now when something goes wrong it
> takes down khubd and thus a very large part of the entire USB subsystem.
> With proper partitioning, a problem would leave some other task hung and
> the device in an intermediate state, but the rest of usbcore would still
> be able to function in a useful way. Sure, a reboot will be needed to
> clean things up, but maybe the system will work better until then.
It will work unpredictably. If you kill khubd the damage is confined to USB.
Regards
Oliver
-------------------------------------------------------
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
