BoF on hotplugging - summary
Hi people,
here's my summary on a BoF session during the recent Linuxkongress in Cologne.
Regards
Oliver
BoF on USB and Hotplugging
Participants:
Brad Hards(USB), Tim Jansen(KDE), Oliver Neukum(USB), one unnamed and largely silent GNOME coder and several other interested participants. Unfortunately nobody of XFree was present.
Topics:
- definitions
- delivering events
- information needed by user space
- device numbers, names and associated stuff
Definitions: I remember nothing noteworthy
Delivering events:
General consensus was that there's nothing wrong in that regard. The KDE and GNOME people would be quite happy with the hotplugging scripts writing all information they have to a named pipe or something similar. It seems that nobody really cares much about the exact mechanism.
A suggestion was made that a demon should be introduced. That was not discussed fully. Later discussion with the X people which are to be continued shows that the X people would want to introduce an X extension for device discovery and notification issues.
Information needed by user space:
Items of consensus:
- physical path and all available device ids must be delivered
- groupings of devices must be delivered
- most crucial item: user space needs a mapping between physical and logical device
- user space wants a device _name_
- driverfs and the input layer must be documented
A partial solution to the issues was found.
There needs to be a second kind of hotplugging event that is generated upon "associating" a device to a driver
Device numbers, names and associated stuff
Items of consensus:
- device numbers are a bad idea
- there needs to be some "dynamic element"
There was absolute disagreement over devfs.
Oppinions ranged from "devfs must go away" to "hotplugging without devfs is obviously stupid"
-------------------------------------------------------
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 1 line · Oliver Neukum
- groupings of devices must be delivered
This is an important issue that might be worth expanding on.
Some of the newer devices have multiple logical "interfaces" (read this in a loose sense, not meant to equal USB interfaces). Somethimes the device offers all the interfaces at once, sometimes you can choose one or the other.
USB example - speakers. There is an audio interface (usually with some selection of sampling rates, which you might consider to be a choose 1 of N interfaces) and a HID interface (for button controlling volume, etc).
We need some way of selecting the interfaces we want, and associating them into sensible groups (so that if I have two speakers, and a multimedia keyboard; I can get the volume controls on each set of speakers to only control those speakers, and the volume control keys on my keyboard to control the built-in (PCI bus) soundcard.
This is really a policy thing, and the kernel is probably provding enough when we have topology, but there is a lot of userspace work to be done.
Quoted 1 line
- driverfs and the input layer must be documented
I'm working on the input layer docs now.
Greg: do you know of any plans to document how userspace should use driverfs?
Thanks for writing this up Oliver.
Brad
- --
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9j5ItW6pHgIdAuOMRAli6AKCAWxa4C1hHGwOII0zXExIuSvkIwwCdGVd4 7Wa+Bl46HL2f53soQNWIRXM=OSwE
-----END PGP SIGNATURE-----
-------------------------------------------------------
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 · Brad Hards
Greg: do you know of any plans to document how userspace should use driverfs?
Yes, but the people involved are madly working to get the driverfs code finished. It wouldn't make sense to write up documents that will be wrong at this time.
But in short, take a look at the driverfs tree right now. If there's anything in there that doesn't make sense, please let us know.
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 4 lines · Oliver Neukum
There was absolute disagreement over devfs.
Oppinions ranged from "devfs must go away" to "hotplugging without devfs is obviously stupid"
devfs will be redundant soon, and probably eventually just removed from the kernel all together. See the old threads on lkml for the reasoning behind this statement.
Oliver, thanks for writing this up.
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 7 lines · Oliver Neukum
Information needed by user space:
Items of consensus:
- physical path and all available device ids must be delivered
- groupings of devices must be delivered
- most crucial item: user space needs a mapping between physical and logical device - user space wants a device _name_
- driverfs and the input layer must be documented
To go a step back, I think there are three four things that need to be done:
1. get a list of all device that implement an interface (eg. OSS, ALSA or V4L) and get information about the devices that can be presented to the user (name, manufacturer, bus). In an ideal world, the information could be retrieved without using the (OSS|V4l...) interface, so desktop environments can have a single dialog/widget for displaying all devices of a type. And it must be possible to get the path to the /dev node(s) that represent the device.
Use case:
- user wants to record sound
- app presents user all devices that can record sound (for example on-board sound, sound card, USB headset, webcams with build-in microphone - my computer has 4 OSS devices)
- user selects one of them
- application uses the selected sound device
2. identify a device. An application should be able to 'remember' which device a user selected. When the user turns the computer off, the application should be able to find the device that the user has selected before. Even if it is in a different port or the user added a second device of the same type. This is not always possible, as many devices do not have a unique serial number, but the system should try to guess as well as possible. So if there is a serial number, use it. If there is no other information available, try to guess it using the port or the hub the device is/was connected to.
Use case:
- a user has two USB printers and selects one of them
- the user turns off the computer and the printers
- the next day, the user turns the computer the printer on again. Note that the user may or may not turn on the printers in the same order. If the user chooses a different order, the device nodes of the printers have changed
- when the user prints, he should print using the printer he selected yesterday
3. id for application-level drivers. For some devices you need an 'application-level' driver. Examples are 'snapshot' buttons on webcams, the 'scan' and 'copy' buttons on scanners and dozens of useless USB devices that can indicate that you have got an email (like this one:
http://www.dytoy.com/e638.html). Most of them use a HID driver on the kernel-side. But they are completely useless unless there is a integration with the actual application, so the DE can start a scanner application when the user presses the 'scan' button, or a mail program can raise the flag of the email indicator. To do this, it is neccessary that you can get an identifier of the device (for a USB device, such an identifier would be bus identifier + vendor id + model id). Using the identifier and the /dev node path an 'application-level' driver could then do the functionality that the user expects
Use case:
- user has a scanner with a 'copy' button
- user presses the 'copy' button
- the desktop environment starts an application that scans a page and prints it on the default printer
4. Identify sub-devices of a compound device. Many devices have several sub-devices with independent drivers. For example the Philips ToUCam is a USB device that has a camera (V4L), microphone (OSS) and a 'snapshot' button (HID). It is often important for an application to know which sub-devices share the same physical device.
Use case:
- User has two ToUCams
- user presses the 'snapshot' button
- the camera, whose button the user pressed, makes a snapshot
bye...
-------------------------------------------------------
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
A suggestion was made that a demon should be introduced. That was not discussed fully. Later discussion with the X people which are to be continued shows that the X people would want to introduce an X extension for device discovery and notification issues.
How about adding a new kind of hotplug agent: daemons that see events delivered through a filesystem socket or pipe, like /var/run/hotplug/input.agent? Simple to add.
Easy to integrate with, and lots of people are already working with similar models. It'd move the X discussions to a more useful stage: here's the device, now what? :)
I suspect few of those daemons would ever be "part of" the hotplug system, except in terms of hearing from it through the /var/run/hotplug/*.agent files.
Quoted 3 lines
Information needed by user space:
Items of consensus:
- physical path and all available device ids must be delivered
I'll submit a 2.5 patch to do that for USB, which currently does not expose that through hotplug. (PCI does.) This is a simple thing to add to 2.4.20, too, so updated user mode tools (that know about physical paths) wouldn't need 2.5 to run.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel