(1) We don't want connect processing
(registering interfaces in the driver model and probing device drivers,
maybe other things too) and/or disconnect processing (detaching drivers
and deregistering interfaces, etc.) to occur simultaneously in different
threads.
Why not? It'd certainly make for a more robust system, when that task hits problems with some device or driver: only the problematic device/driver should lock up. The serialization in sysfs suffices ... it allows simultaneous "processing", with only some critical sections needing serialization.
The relevant usb code is monolithic, and splitting out the parts will necessarily expose the things that can/can't be concurrent.
- Enumerating through the end of "address zero" stage, which puts the device into configuration 0. Clearly, only one "address zero" (STATE_DEFAULT) device per bus, but any number in later states.
- Picking a configuration. If there's only one, the kernel can clearly choose it. If there's only one that meets the hub's power budget, likewise.
Otherwise the kernel should leave this to some task in userspace. So there's natural concurrency there, between that task and (today's) khubd, as well as between busses.
- 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.
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).
Now consider configuration changes. They shouldn't be a big problem either. They should simply repeat the same processing that
Right, a code-shuffling patch could be developed very quickly.
usb_disconnect() does now to remove drivers and interfaces, issue the
set-configuration request, and then probe the new interfaces. In fact,
there's no reason why the last two steps here shouldn't be carried out by
the same code that handles new device connections, and no reason why the first step shouldn't be carried out by the same code that handles device disconnects.
That is, the same _modified_ code. Right now there's one great big usb_new_device() routine that mixes up two very different stages
- set address, fetch device and config descriptors
- set configuration, update sysfs
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).
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.
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.
While things like marking devices as NOTATTACHED right when the hub status interrupt data reports it "gone" would cut down on false error reports ... vs waiting not only for khubd to be scheduled, but also to get around to handling that end its 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.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
