On Tue, Oct 08, 2002 at 10:02:59AM -0700, David Brownell wrote: > Greg KH wrote: > >As almost no one noticed, I changed the environment variables that > >/sbin/hotplug is called with in 2.5.40 :) > > I look at it just a bit differently ... where previously it only > issued calls for the first interface (typically that's all there is), > now it issues calls for every interface, _plus_ a call for a new kind > of thing never before seen through hotplug, a "usb device". > > I really like the "event for each interface" change, though I'd > like it a bit better if we could tell this 2.5+ behavior apart > from earlier ones -- so hotplug agents can act accordingly.
What needs to be different? > Its that new type of hotplug event that makes recent kernels trigger > syslog messages about "Bad USB agent invocation". Hey, it's not my fault you have good error checking :) Seriously, we're going to have to upgrade the hotplug scripts for 2.5 anyway, so this problem will go away soon enough. > >Now I know this overloads the existing DEVICE usage for USB devices, but > >I think we can determine what do properly (basically just test for > >DEVFS, and if it's not set, then we are looking at the driverfs entry > >for the device.) > > I'd rather see these changes: > > - This new parameter to every (!!) hotplug event gets renamed to > KFS_DEVICE (assuming that's the new driverfs name). I like Pat's suggestion of DEV_PATH. Does anyone object to this? > Hotplug agents will need to access KFS data *and* talk to the > device (and its drivers) using the DEVICE= path. Plus, if this > is present we know we don't need to ask 'usbmodules' to scan > other interfaces for us. (That often triggers other problems.) Wait, why does anyone need to use the usbfs path (what is specified by DEVICE= in the usb code)? All of the info that usbmodules used to get is now present in DEV_PATH, right? If not, let me know. > - Don't make hotplug calls for USB devices until we have something > for them to do. (Essentially these are a new class of event.) Why not? That lets us load drivers based on vendor and product id. The interface specific calls let us load protocol specific drivers, giving us a semblance of heirachy that a lot of people used to want a few years ago (and Johannes provided a patch for a long time ago.) And if the hotplug scripts don't want to do anything with this event, it's quite easy to ignore :) > The example that comes to mind is policy agents using those > events to choose a non-default device configuration. But USB > needs a bunch of work before such things become practical. The USB core needs it? Or the hotplug scripts? I'm curious about this, as I'm looking at a device that might need to have it's second configuration enabled if it's running on Linux, yet the default config is for when running on Windows. > >I also created a lot of individual driverfs files for the USB device, > >basically everything that used to be specified by a environment variable > >in the call to /sbin/hotplug, is now a value in a file. So ideally, we > >can get rid of those other variables for the USB call, and just rely on > >the info present in driverfs. > > That'd only work if both KFS_DEVICE and DEVICE are simultaneously available. > See above ... :) I wouldn't de-support the other parameters for quite > a while, though it's certainly good to have such improved flexibility. Well, with a rename to DEV_PATH that should work out fine. Also, any reason to keep the DEVFS variable? It's wrongly named, and doesn't look like anyone uses it. thanks, greg k-h ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
