BoF on hotplugging - summary

BoF on hotplugging - summary

[Oliver Neukum]

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: BoF on hotplugging - summary

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 24 Sep 2002 08:00, Oliver Neukum wrote:
> - 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.

> - 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: BoF on hotplugging - summary

[Greg KH]

On Tue, Sep 24, 2002 at 08:14:05AM +1000, Brad Hards wrote:
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: BoF on hotplugging - summary

[Greg KH]

On Tue, Sep 24, 2002 at 12:00:20AM +0200, Oliver Neukum wrote:
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: BoF on hotplugging - summary

[Tim Jansen]

On Tuesday 24 September 2002 00:00, Oliver Neukum wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: BoF on hotplugging - summary

[David Brownell]

> 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.



> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel