Re: communicating with user login sessions

[Greg KH <greg@kroah.com>]

On Fri, Apr 18, 2003 at 01:39:05AM -0400, Havoc Pennington wrote:
> 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

The kernel emits a hotplug event for this today, on 2.4 and 2.5.

>  b) we might then notify userspace that a major/minor 
>     has been created, i.e. there is a new usable device

The kernel emits a hotplug event for this today for some devices on 2.5.
I'm working on making that happen for all devices by the time we make it
to 2.6.

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

Yes.

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

Exactly.

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

Both.  Well, traditionally only for a), as that's all we had.  The stuff
for b) will show up in 2.5.68 and beyond.

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

Multiple handlers is just an easy way for different programs to be run
when the hotplug event is generated.  Right now we have the following
things to do when a) happens:
	- try to load a driver
	- run devlabel
	- load firmware if needed
	- send D-BUS event for other programs to listen to.
	- lots of custom devices want a script run

All of those tasks today have to patch the existing hotplug scripts in
order to get run (or just point /proc/sys/kernel/hotplug to their
program.  I'm just trying to provide a framework that all of the above
can be done without steping on other's toes.  Running all of the
programs linked in a directory solves this issue (much like the init.d
stuff).

Does that help out?

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

That all looks great, and reasonable.  Nice job.

Now to implement it all... :)

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