/sbin/hotplug invocation for USB devices in 2.5.40
As almost no one noticed, I changed the environment variables that /sbin/hotplug is called with in 2.5.40 :)
This is what has changed from the previously documented info at
http://linux-hotplug.sourceforge.net/?selected=usb
For USB devices, /sbin/hotplug is called for the main device, and every interface. For the interfaces, the info in the above link is still set. Previously, /sbin/hotplug only got called once, and we only sent the first interface's information. We should now be able to handle compound devices much easier.
For the USB device (not the interface), the only environment variable is:
DEVICE = <place in driverfs tree for the device>
For the interface, it's the same as it used to be.
This variable is also set for every other /sbin/hotplug call that happens (which is now for every type of device in the kernel, not just the types we used to have.)
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 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.
I'll be doing the same thing for PCI devices to try to get rid of their extra variables.
Does this all sound ok? Problematic? Even make any sense?
thanks,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Greg KH
As almost no one noticed, I changed the environment variables that
/sbin/hotplugis 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.
Its that new type of hotplug event that makes recent kernels trigger syslog messages about "Bad USB agent invocation".
Quoted 4 lines
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).
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.)
- Don't make hotplug calls for USB devices until we have something for them to do. (Essentially these are a new class of event.)
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.
I think both of those would be simple changes to make. They'd greatly improve backward compatibility, while letting us do better things on Linux Next Generation systems.
Quoted 5 lines
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.
By the way, what's the cost of a driverfs attribute on a 'struct device'? Each USB device now has over a dozen of them.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines
Quoted 5 lines
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).
What about DEVPATH, since that's what it is, right?
Quoted 2 lines
By the way, what's the cost of a driverfs attribute on a 'struct device'? Each USB device now has over a dozen of them.
32 bytes/attribute + size of the function. But, attributes are reused across devices, so the total data cost is 32 x ~16 = 512.
-pat
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines
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.I'll be doing the same thing for PCI devices to try to get rid of their extra variables.
Does this all sound ok? Problematic? Even make any sense?
At first glance problematic. Invocation with enviromental variables is atomic, reading values from driverfs is not.
I'll have a thorough look at the matter.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Patrick Mochel
Quoted 5 lines
Quoted 4 lines
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.)
Quoted 7 lines
Quoted 4 lines
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).What about DEVPATH, since that's what it is, right?
Well, it's different from usb_device->devpath ... devpath is just one component of the KFS path. One that's repeated because of that requirement that names assigned by a bus be unique across the whole system, making it easier to automate that symlinking. :)
It's not the only filesystem path used to access the device. Would using KFS_DEVICE really be a problem?
Quoted 6 lines
Quoted 2 lines
By the way, what's the cost of a driverfs attribute on a 'struct device'? Each USB device now has over a dozen of them.
32 bytes/attribute + size of the function. But, attributes are reused across devices, so the total data cost is 32 x ~16 = 512.
"Reused" meaning shared attributes like "name" and "power", I guess.
USB devices have at least one interface, and each will have six attributes (including name+power). So 32 x ~24 = 768 bytes minimum, on top of other costs. These start to add up.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines
- Don't make hotplug calls for USB devices until we have something for them to do. (Essentially these are a new class of event.)
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.
And reporting the thing to a desktop enviroment. The cost is small and the thing is potentially useful.
We discussed such stuff in Cologne and came to the conclusion that user space wants all information on device<->interface relationship it can get.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · David Brownell
Quoted 2 lines · Greg KH
As almost no one noticed, I changed the environment variables that
/sbin/hotplugis called with in 2.5.40 :)
Quoted 8 lines
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?
Quoted 2 lines
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.
Quoted 9 lines
Quoted 4 lines
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?
Quoted 4 lines
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.
Quoted 2 lines
- 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 :)
Quoted 3 lines
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.
Quoted 9 lines
Quoted 5 lines
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_DEVICEand 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
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · David Brownell
Quoted 2 lines
What about DEVPATH, since that's what it is, right?
Well, it's different from
usb_device->devpath... devpath is just one component of the KFS path. One that's repeated because of that requirement that names assigned by a bus be unique across the whole system, making it easier to automate that symlinking. :)It's not the only filesystem path used to access the device. Would using
KFS_DEVICEreally be a problem?
No, but DEVPATH is nicer looking imho :)
thanks,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Quoted 3 lines
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?
As I suggested, a KFS-only environment variable would be fine.
Quoted 9 lines
Quoted 4 lines
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.
I think device speed is still unavailable through KFS, and I suspect the extra audio descriptor bytes aren't exposed, but other than that the read-only access modes are about equivalent.
But USBFS lets you interact with the device, and every user mode driver (or configuration tool) relies on that. Many of them hook up through hotplug. KFS doesn't; which is why the agents will continue to need the USBFS path.
There's also the "coldplug" situation. KFS _could_ remember which devices didn't have hotplug events issued (a device state flag) and rescan its tree to issue them, after the kernel's come up enough that /sbin/hotplug can safely be called. Only solving that issue lets us completely get rid of "usbmodules".
Quoted 2 lines
Also, any reason to keep the DEVFS variable? It's wrongly named, and doesn't look like anyone uses it.
Not any longer. But update the docs (on the hotplug website).
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · David Brownell
I think device speed is still unavailable through KFS,
Good catch, I'll go add that.
Quoted 2 lines
and I suspect the extra audio descriptor bytes aren't exposed, but other than that the read-only access modes are about equivalent.
That should go into the audio driver, not the usb core.
Quoted 4 lines
But USBFS lets you interact with the device, and every user mode driver (or configuration tool) relies on that. Many of them hook up through hotplug. KFS doesn't; which is why the agents will continue to need the USBFS path.
I want to remove the fact that usbfs is being used by the hotplug scripts. I don't care about any userspace drivers or configuration scripts, they can determine the usbfs location from the driverfs/kfs device already.
Quoted 5 lines
There's also the "coldplug" situation. KFS _could_ remember which devices didn't have hotplug events issued (a device state flag) and rescan its tree to issue them, after the kernel's come up enough that
/sbin/hotplugcan safely be called. Only solving that issue lets us completely get rid of "usbmodules".
No, kfs isn't going to do a "coldplug" store and replay thing. What is going to happen is /sbin/hotplug will be present early in the boot due to initramfs, so the proper modules will already be loaded. If userspace wants to walk the driverfs/kfs tree when init starts up, that's up to it.
And yes, I really want to get rid of usbmodules too :)
Quoted 4 lines
Quoted 2 lines
Also, any reason to keep the DEVFS variable? It's wrongly named, and doesn't look like anyone uses it.
Not any longer. But update the docs (on the hotplug website).
Will do.
thanks,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
Quoted 3 lines
- 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.)
I didn't know we had any problems loading drivers based on vendor+product ... sure seems like I've been doing it for a few years now!
Today's MODULE_DEVICE_TABLE, with flags, should be isomorphic to as much of a hierachy as is really needed. I seem to recall Johannes saying his patch didn't do everything MSFT seemed to say needed doing, either.
Quoted 10 lines
Quoted 3 lines
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.
The usbcore code is pretty confused about changing configurations. As I recall, it doesn't even bother unbinding drivers from the first configuration's interfaces when it sets a new config, so it's just accidental if it works safely (no drivers bound yet, no urbs in progresss, and so on).
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Oliver Neukum
Quoted 6 lines
- Don't make hotplug calls for USB devices until we have something for them to do. (Essentially these are a new class of event.)
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.
And reporting the thing to a desktop enviroment.
The software I've heard of that does such things today is perfectly happy with today's interface level notification.
Quoted 1 line
The cost is small and the thing is potentially useful.
Equivalently: it's not free, and we don't know what it'd be good for.
That "small and potentially useful" argument is the essence of feature creep, which is why I don't like it. I'd far rather see some examples of improvements it would enable ... but I don't think there are any, since it'd be just a subset of what we can already do without such calls.
Quoted 3 lines
We discussed such stuff in Cologne and came to the conclusion that user space wants all information on device<->interface relationship it can get.
It's sitting there in KFS already, nobody's proposing that it be removed.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · David Brownell
Quoted 5 lines
Quoted 3 lines
- Don't make hotplug calls for USB devices until we have something for them to do. (Essentially these are a new class of event.)
Quoted 8 lines
Quoted 4 lines
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.)
I didn't know we had any problems loading drivers based on vendor+product
...
sure seems like I've been doing it for a few years now!
Doh, nevermind, I shouldn't write on an empty stomach...
Quoted 3 lines
Today's
MODULE_DEVICE_TABLE, with flags, should be isomorphic to as much of a hierachy as is really needed. I seem to recall Johannes saying his patch didn't do everything MSFT seemed to say needed doing, either.
I also remember the MSFT documentation being to complex for what is really needed :)
Anyway, it was just a suggestion, I need to update diet-hotplug to work with the new fields and see if I can get away with just using the driverfs/kfs files.
thanks,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
Quoted 5 lines
But USBFS lets you interact with the device, and every user mode driver (or configuration tool) relies on that. Many of them hook up through hotplug. KFS doesn't; which is why the agents will continue to need the USBFS path.
I want to remove the fact that usbfs is being used by the hotplug scripts.
So far as the "load the driver" part of those scripts, I agree it shouldn't be needed. But hotplug agents do more than just loading drivers
Quoted 3 lines
I don't care about any userspace drivers or configuration
scripts, they can determine the usbfs location from the driverfs/kfs device already.
Not the last time I looked they couldn't !!
But even if they could, then the hotplug scripts would want to set the usbfs DEVICE= parameter before calling setup/config scripts,
which often call userspace drivers. Intentionally breaking such
third party software is not somehing I'm keen on.
Quoted 8 lines
Quoted 5 lines
There's also the "coldplug" situation. KFS _could_ remember which devices didn't have hotplug events issued (a device state flag) and rescan its tree to issue them, after the kernel's come up enough that
/sbin/hotplugcan safely be called. Only solving that issue lets us completely get rid of "usbmodules".No, kfs isn't going to do a "coldplug" store and replay thing.
I've yet to hear another scheme that would solve the whole "coldplug" problem, though ... there always seems to be some case (like the right driver being missing from initramfs) that is more naturally handled just by deferring the event report.
Not store/replay -- one bit per device, and ftw() code that could likely be removed after the system's running.
Quoted 6 lines
What is going to happen is
/sbin/hotplugwill be present early in the boot due to initramfs, so the proper modules will already be loaded. If userspace wants to walk the driverfs/kfs tree when init starts up, that's up to it.And yes, I really want to get rid of usbmodules too :)
I've heard of this initramfs scheme, but it's almost Hallowe'en ... but maybe this falls under the "scarey costume" exception! :)
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · David Brownell
Quoted 3 lines
I don't care about any userspace drivers or configuration
scripts, they can determine the usbfs location from the driverfs/kfs device already.Not the last time I looked they couldn't !!
But even if they could, then the hotplug scripts would want to set the usbfs DEVICE= parameter before calling setup/config scripts,
which often call userspace drivers. Intentionally breaking such
third party software is not somehing I'm keen on.
Ok, this makes sense. I've fixed the DEVICE overloading with the last round of patches I sent off, so we shouldn't have this problem anymore.
thanks,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel