I think at this point we're pretty much in agreement. On Wed, 13 Aug 2003, David Brownell wrote:
> Yes, choosing between those assumptions/approaches implies design choices > beyond "usb_set_configuration() needs a task context" and "kernel code > other than khubd should be able to choose configurations". > > > > Many of the advantages of the second choice would be negated by the fact > > that config changes can be requested via usbfs or sysfs at any time. > > How could a constraint on both choices affect only one of them? :) > I don't see any negation. [This is moot as we aren't going to adopt the "callback" approach, at least not for the time being. Nevertheless...] The "constraint" that usbfs and sysfs can request config changes at any time only affects the second choice, because the first choice amounts to saying that drivers can also request config changes at any time. On the face of it, the second choice (allowing drivers to change the config only at controlled times) would make certain things easier: not having to worry about locking or interfering with probe/disconnect. But those advantages aren't realized because non-drivers can still make config changes whenever they want. > > What about drivers that are loaded by hand, well after the initial device > > setup has finished? Would they get a say in choosing a configuration? > > Certainly they should. In the same way their probe() gets called. > It's another way to (implicitly) request a config change. > > Alternatively, write the sysfs bConfigurationValue after modprobe. The disadvantage to that is it requires knowledge of what configurations are supported to be divided between the driver and a user-mode helper. > >>I see different assumptions: namely, that usb_set_configuration() > >>should be available to device drivers in almost all contexts, not > >>just in controlled configure() contexts. > > > > > > Don't forget, this discussion applies equally well to usb_reset_device() > > in the "device morphed" pathway. I doubt you want to restrict that > > capability to these configure() contexts. > > No, but I think that the "morphed" case should go through complete > re-enumeration, from khubd as usual, instead of making a special case. > Enumeration is one of those contexts, and that "hand off to khubd" > is something you had pointed out was essential. Okay, makes sense. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
