> think we're in any disagreement here. Imagine the chaos if one thread was
> probing drivers for a device at the same time another thread was handling
> the device's disconnection while simultaneously a third thread was trying
> to change the active configuration.
As these code paths are not relevant to performance, IMHO we should
go for full serialisation per device and driver.
[..]
> The details of this are not so important to my proposal because it doesn't
> involve any USB communication, merely examining host-side data
> structures.
Right. What we have today works. We simple pick a sane default
and leave the rest to the hotplug scripts.
> > - Actually setting that configuration. Update sysfs etc.
> > (Including "set config 0", which is a kind of reset.)
> >
> > This is the time consuming and error prone stuff. The
> > binding is a side effect of adding interfaces to sysfs,
> > which can only exist if config value != 0. It needs
> > to be serialized within scope of a given device, since
> > some drivers use multiple interfaces, but no more.
>
> Agreed.
It needs to be serialised with respect to reset as well. In
2.5 it is.
> > Device reset is a partial re-enmeration. I suspect some
> > of the issues there would go better if it were more of
> > a full re-enumeration (you said something similar). And
> > again, that's normally done in some other thread (say,
> > scsi-eh).
>
> It overlaps the first of your tasks above: everything up to the ADDRESS
> state. There's no need to pick a configuration; we simply re-use the one
> previously in effect. The interfaces, sysfs stuff, drivers, and so on
If we can. We need to deal with errors here.
> persist throughout the process with no change. Again, these stages have
> to be serialized only within the scope of a single device, no more. But
> device resets occur so infrequently that we don't lose anything by making
> them globally serial.
Right.
> > The "update sysfs" should be part of usb_set_configuration(),
> > clearly ... including setting to config 0, which should be
> > similar to "disconnect device" logic except that the device,
> > and ep0, state remains (but no sysfs interface state).
>
> usb_set_configuration() involves two parts. First shut down the current
> config (skip if the old config is 0). Then install the new one (skip if
> the new config is 0). The second part should be shared with the updated
> version of usb_new_device(), the first part with the updated version of
> usb_disconnect().
Right.
> > And "echo $CONFIG_VALUE > bConfigurationValue" sysfs hooks
> > will certainly need usb_set_configuration() to do all the
> > sysfs stuff that it currently doesn't do.
>
> Absolutely.
Details.
> > >>And <linux/workqueue.h> can be used to make keventd do things
> > >>in parallel, so that misbehavior through one port can't break
> > >>the others. Dedicated thread not necessary.
> > >
> > > That's true. But on the other hand, if the actions being requested are
> > > things that khubd is doing anyway, it hardly seems necessary to go to a
> > > different thread. Also, khubd is _already_ a big single point of
> > > failure.
> >
> > That was the notion: get rid of it. A lot of the problems
> > with the current enumeration logic come from how it's all
> > so monolithic. And khubd is a part of that.
>
> What do you propose? Put most of the usb_hub_port_connect_change() code
> into a work queue that can run independently of khubd?
Then you need to introduce ordering code which you get for free if
a thread works through a FIFO queue.
> > > This is a bit confusing... Hub status interrupt data only indicates
> > > that a port has undergone a status change. It doesn't say what the
> > > cause of the change was; for that khubd has to make a port status
> > > request. So there doesn't seem to be any way to carry out this
> > > suggestion.
> >
> > Wrong detail... :) We're still flagging NOTATTACHED pretty late,
> > so we get more false error reports than we need. The instant
> > we know a port is gone, the hub driver can mark every child of
> > that port (other hubs too!) NOTATTACHED even if it has to take
> > its own sweet time to disconnect all the drivers from some
> > child of that port.
>
> Well, yes. That could be done right now, independently of all the other
> changes discussed here.
Right.
> Your reply did not address the main point of my previous post, which was
> the implications of having to serialize the operations for each individual
> device. There are lots of steps involved here:
>
> Reset the port, Set the device address, Download the descriptors,
> Select a configuration, Set the configuration, Set the interfaces,
> Create sysfs entries for the interfaces, Delete sysfs entries, ...
>
> plus plenty of little ones I left out. What's the best way to arrange
> that these things only happen one at a time for each device (one at a time
> per bus for some of them)? How do we do that and still permit a driver to
> request a configuration change, a device reset, or a re-enumeration?
For this very reason usb_device_reset() exists in a very without locking.
So that it can be done in probe(). I tried a lot of games with rw-semaphores
but in the end that doesn't pay off. We might go for a lock with ownership
but that doesn't sound attractive either.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
