Re: communicating with user login sessions

[Havoc Pennington <hp@redhat.com>]

On Thu, Apr 17, 2003 at 04:50:14PM -0700, David Brownell wrote: 
> I've added a link to D-Bus right there.

Thanks!
 
> How would you speculate that a hotplug event should be delivered
> to the "system message bus"?   I'm not quite sure how the kernel
> would be expected to authenticate itself, or whether it should.
> If there's going to be a daemon collecting kernel events, I tend
> to think it should be able to read them directly ...

Alan was kind enough to explain some of how devices work to me last
week. If I understand correctly, there are really two phases to
hotplugging a device.

There was just some discussion of this here:
http://www.xfree86.org/pipermail/forum/2003-April/001307.html
http://www.xfree86.org/pipermail/forum/2003-April/001328.html
http://www.xfree86.org/pipermail/forum/2003-April/001329.html

Specifically, the relevant bit of those mails is that there's a
multi-phase process, and during that process there are two separate
places we might want to kick out to userspace.

In brief:
 a) we might first notify userspace that an unknown 
    device has appeared on the USB or other bus
 b) we might then notify userspace that a major/minor 
    has been created, i.e. there is a new usable device

So my understanding is that for a), we pretty much just want some
simple-as-possible low-overhead single process that loads the right
driver for the given device. This driver then creates 0-N major/minor.

For b), lots of apps might want to know, and they might be running in
a user login session. For example, that's the point where your desktop
might want to display a camera icon if you plug in a camera.

Please correct this if I'm confused, because I really am an
Xlib-and-above programmer most of the time. ;-)

It seems to me that D-BUS is really nice for b), where we want to tell
the user session about a new usable device. This is kind of the
canonical purpose of D-BUS. But I'm not sure it's all that useful for
a).

The one exception is that as part of a), you might sometimes want to
ask the user what driver to load. So you could use D-BUS for that.
"Is this a mass storage device?" etc. Or more simply, D-BUS could be
used to show an error message: "I don't know what you just plugged in,
but I'm ignoring it." That way you don't plug in an unknown device and
just get silence, you have some indication that the device works even
if there's no driver.

When people say "hotplug" do they mean both a) and b) or only a)? 

I'm a bit unclear on why you want multiple handlers for a) as people
have discussed recently - my simplistic understanding is that all you
can do with a device in phase a) is load a driver for it - so I think
I'm missing some data.


Anyway, I've been trying to get some notes together on how devices
might appear to the applications/desktop layer of the OS.  They aren't
really presentable, but part of the notes are the appended sketch of
"what happens when plugging in a camera" - I'd love comments on it.

Havoc


(Note: In this sequence of events, the word "system" means an appropriate
conglomerate of kernel and userspace features, it does not imply
kernelspace.)

 - I plug in my new digital camera.

 - If the camera's interface type (e.g. USB) supports it, the presence
   of a new device is noticed without user intervention.

 - The system gets whatever information is available from the device
   about the hardware model. Vendor, ProdID, whatever it can get.

 - The system consults a mapping from hardware model information to
   driver information. This mapping is created by merging three
   sources of information: user-provided information, OEM-provided
   information, and operating-system-vendor-provided information.

 - If no driver is found, the system delivers a notification to the
   desktop environment, and the desktop environment informs the user
   that the device is not supported. Alternatively, the desktop
   environment asks the user which driver to try and passes the answer
   back to the system; the system a) tries that driver and b) saves
   the driver information in the above-mentioned mapping.

   [D-BUS proposed for implementation of this]

 - The system loads a driver once one has been found in the mapping, or
   added to the mapping.

 - A major/minor pair is created for the device, along with a /dev
   file if necessary.

 - A notification is sent out that a new major/minor pair has been
   created.

   [D-BUS proposed for implementation of this]

 - The user's desktop environment asks the system what sort of device
   is represented by the major/minor pair: camera, scanner, printer,
   etc.

 - If the system does not know, it says "device type is unknown."

 - If the device type is unknown, the desktop environment asks the
   user to provide it. "What did you just plug in?"

 - After the user provides this information, the desktop environment
   passes it back to the system. The system records a mapping from the
   hardware model identifying information to the device type. Next
   time a major/minor pair is created for a device with the same model
   information, the system will report its type accordingly.

 - The desktop environment allows the user to interact with the device
   in device-appropriate ways. For example, view images from a camera,
   monitor errors from a printer, or whatever.




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