communicating with user login sessions

Hi,

There's this text on the hotplug web site, not sure it's up to date:

A gap in current Linux support is that policies with any sort of dynamic "interact with user" component aren't currently supported. For example, that's often needed the first time a network adapter or printer is connected, and to determine appropriate places to mount disk drives. It would seem that such actions could be supported for any case where a responsible human can be identified: single user workstations, or any system which is remotely administered. This is a classic "remote sysadmin" problem, where in this case hotplugging needs to deliver an event from one security domain (operating system processes) to another (desktop for logged-in user, or remote sysadmin), and any effective response must go the other way. At this writing, Linux doesn't have widely adopted solutions to such problems.

This is by no means specific to device hotplugging - there's a general problem of delivering events from the OS out to user login sessions. Non-hotplug events might be things like "printer queue has changed" (from the lpd daemon), or "I need a password now" (from the VPN subsystem).

I'm working on some code with some other people that may provide a nice solution to this problem:
http://www.freedesktop.org/software/dbus/

I don't know if people outside of the desktop world have heard of it yet, or whether there are already similar solutions in progress for hotplug specifically.

With D-BUS, the same code is used in three different use cases:

- two applications communicate directly with each other by exchanging messages
- applications send/receive broadcasts across a per-user per-login-session message bus daemon
- applications send/receive broadcasts across a systemwide per-machine message bus daemon

How it works:

- there's a library which provides general "exchange messages between two applications" functionality; it handles authentication, creating a network transport, and serializing/unserializing messages to push them over the wire

- on top of that general functionality, we've built a message bus daemon

- the message bus daemon can be customized via configuration file to be systemwide or per-user-login-session.
(See http://www.freedesktop.org/software/dbus/doc/config-file.txt)

As an inside-login-session IPC mechanism, D-BUS gives us a way to link different kinds of application (GNOME, KDE, plain old command line or Xlib). This distinguishes it from tightly-bound-to-the-desktop APIs such as Bonobo and DCOP, that require more buy-in to the GNOME/KDE frameworks.

My understanding of how D-BUS would interact with hotplug is that the hotplug scripts or daemon would briefly connect to the message bus, inject a broadcast message, then disconnect again. This could be done by linking to the D-BUS library, or by calling a simple command line tool that linked to the D-BUS library. Or for efficiency, a daemon could maintain a continuous connection to the message bus.

The mostly-but-not-completely-implemented plan is that there are access controls built in to the message bus. So it's possible to specify that only certain users or certain groups can send or receive certain kinds of message.

The hope is that by making D-BUS useful in three different contexts, portable to many operating systems, and X-style-licensed, it will be widely used and will thus be robust and something that application authors are comfortable relying on. We're also hoping to see GNOME and KDE both adopt the system, which should help make it widely available. If all desktop apps are linking to D-BUS anyhow, then it would be really easy and simple for any app to monitor the systemwide message bus and implement hardware-related features.

There is nothing X-specific about D-BUS, and it does not link to Xlib (or indeed to much of anything - it's basically dependency-free with the exception of "some XML parser to load the config file" - even the XML parser dependency is on the daemon binary, not on the shared lib).

Some of the interesting features of D-BUS so far:
- 63% of basic blocks covered by "make check" tests
- dual licensed your choice of AFL (MIT/X license equivalent) or GPL
- 100% API documentation, substantial internals documentation
- partially complete protocol specification
- significant amount of code implemented

Caveats:
- the library is about 50% test code, unless you build with --disable-asserts --disable-verbose-mode --disable-tests
- don't ship D-BUS in production yet, it has a number of unimplemented yet essential security features (such as timing out unauthenticated connections)
- some stuff is just broken
- the API is still in flux

If this sounds interesting to the hotplug community, I'd hugely appreciate it if people could read some of the D-BUS docs, hop on our mailing list, play with the code, give feedback, or whatever interests you. Right now most of the core desktop developers are on the D-BUS mailing list, but we don't have a lot of representation from hackers working on the system and hardware end of things.

There are a couple of TODO lists on the web page, and help on any of that stuff would be welcome. Perhaps the most invaluable contribution would be any amount of code auditing people have time for, whether it's one file or a complete audit. Third party eyes are always a help.

If D-BUS proves useful for hardware events, I'd like to see a standard set of events spec'd out, and used across all distributions. That way projects such as GNOME and KDE can easily use those events without a bunch of #ifdef SUSE #ifdef RED_HAT kind of stuff.

In any case, feedback is welcome. Specifics of D-BUS that aren't directly related to its use with hotplug are probably best posted to [email protected] rather than this list, I don't want to start an off-topic thread.

Thanks a lot,
Havoc

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Thank you for pointing this project out, I had heard rumors of it, but didn't really know what it was.

That would be great. I have just submitted the existing hotplug kernel/user interface to the LSB for proposal as a potential standard that user programs can interact with. However this looks like a whole lot better interface for all potential user programs to be able to accept kernel messages such as this.

I'll join the mailing list and see how D-BUS works out, at first glance, it looks good.

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

That particular text would still seem to be accurate ... :)

I think the main thing I'd say about that site is that it's not been updated recently, or for 2.5 support. I'd love a volunteer who was interested in updating it, overhauling it, or whatever.

I've added a link to D-Bus right there.

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

- 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

For hotplug events, based on some work I did last year I'd propose the following "must carry":

- argv: the positional parameters
- envp: the named parameters (scoped by argv[1])
- timestamp

That is, leave the format open and type-neutral ... agents interpreting those events may translate them to less generic events. Just having those three things suffices to hold a useful hotplug event log, suitable for later replay, and keeps the event data usefully flexible.

There would of course be non-hotplug events, but nailing that much down would let people experiment with simple solutions like having /sbin/hotplug forward the event through D-Bus ...

- DB

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

Thanks!

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Hmm, that long mail I just sent answered the question "what events go over D-BUS" not "who sends the events to D-BUS" I guess. ;-)

How the events get to D-BUS is something I'd defer to kernel hackers on - I can't say I have an informed opinion. Basically I gather there's some minimal hook to get the event to a userspace process, and that process connects to D-BUS and sends the event.

Easiest way to send an event is with Philip Blundell's dbus-send command line tool from a shell script. Downside of that is that it creates a new connection to the bus and redoes some authentication/handshake work for each event. If that turned out to be a performance issue, you'd probably want some sort of daemon that maintained a permanent connection.

I'll attach two patches Tim Waugh did for the CUPS print daemon and the "eggcups" print queue monitor icon - these are in the rawhide packages. They show what's involved.

Havoc

@@ -42,6 +42,8 @@
 #include <syslog.h>
 #include <grp.h>
 
+#include <dbus/dbus.h>
+
 #if defined(HAVE_MALLOC_H) && defined(HAVE_MALLINFO)
 #  include <malloc.h>
 #endif /* HAVE_MALLOC_H && HAVE_MALLINFO */

@@ -62,6 +64,50 @@
 static void	usage(void);
 
 
+static DBusConnection *dbus_connection = NULL;
+
+static int
+init_dbus (void)
+{
+  DBusConnection *connection;
+  DBusMessage *message, *reply;
+  DBusError error;
+
+  if (dbus_connection &&
+      !dbus_connection_get_is_connected (dbus_connection)) {
+    dbus_connection_unref (dbus_connection);
+    dbus_connection = NULL;
+  }
+  
+  dbus_error_init (&error);
+  connection = dbus_bus_get (DBUS_BUS_SYSTEM, &error);
+  if (connection == NULL) {
+    dbus_error_free (&error);
+    return -1;
+  }
+
+  dbus_connection = connection;
+  return 0;
+}
+
+int dbus_broadcast (void)
+{
+  DBusMessage *message;
+
+  if (!dbus_connection || !dbus_connection_get_is_connected (dbus_connection)) {
+    if (init_dbus () || !dbus_connection)
+      return -1;
+  }
+
+  message = dbus_message_new (DBUS_SERVICE_BROADCAST,
+			      "com.redhat.PrinterSpooler.QueueChanged");
+  dbus_connection_send (dbus_connection, message, NULL);
+  dbus_connection_flush (dbus_connection);
+  dbus_message_unref (message);
+  
+  return 0;
+}
+
 /*
  * 'main()' - Main entry for the CUPS scheduler.
  */

@@ -329,6 +375,8 @@
   if (only_ppds)
     return 0;
 
+  init_dbus ();
+
 #ifdef __sgi
  /*
   * Try to create a fake lpsched lock file if one is not already there.

@@ -171,6 +171,7 @@
 extern void	StartServer(void);
 extern void	StopServer(void);
 
+extern int dbus_broadcast (void);
 
 /*
  * End of "$Id: cupsd.h,v 1.36 2002/12/17 19:00:15 swdev Exp $".

@@ -24,6 +24,9 @@
 
 include ../Makedefs
 
+CFLAGS += `pkg-config --cflags dbus-1.0`
+DBUS_LDFLAGS += `pkg-config --libs dbus-1.0`
+
 CUPSDOBJS =	auth.o banners.o cert.o classes.o client.o conf.o devices.o \
 		dirsvc.o main.o ipp.o listen.o job.o log.o network.o \
 		ppds.o printers.o quotas.o server.o

@@ -80,7 +83,8 @@
 cupsd:	$(CUPSDOBJS) libmime.a ../cups/$(LIBCUPS)
 	echo Linking $@...
 	$(CC) $(LDFLAGS) -o cupsd $(CUPSDOBJS) libmime.a \
-		$(LIBZ) $(SSLLIBS) $(LIBSLP) $(PAMLIBS) $(LIBS) $(LIBMALLOC)
+		$(LIBZ) $(SSLLIBS) $(LIBSLP) $(PAMLIBS) $(LIBS) $(LIBMALLOC) \
+		$(DBUS_LDFLAGS)
 
 
 #

@@ -108,6 +108,7 @@
   else
     Jobs = job;
 
+  dbus_broadcast ();
   return (job);
 }
 

@@ -201,8 +202,11 @@
 	NumJobs --;
       }
 
+      dbus_broadcast ();
       return;
     }
+
+  dbus_broadcast ();
 }
 
 

@@ -48,6 +48,7 @@
 	gobject-2.0
 	gtk+-2.0 >= $GTK_REQUIRED
 	libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED
+	dbus-glib-1.0
 ])
 
 AC_SUBST(EGGCUPS_CFLAGS)

@@ -2,7 +2,7 @@
 /*
  * Copyright (C) 2002 CodeFactory AB
  * Copyright (C) 2002 Richard Hult <[email protected]>
- * Copyright (C) 2002 Tim Waugh <[email protected]>
+ * Copyright (C) 2002, 2003 Tim Waugh <[email protected]>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as

@@ -31,6 +31,8 @@
 #include "lp-intl.h"
 #include "lpegg.h"
 
+gboolean debug = 0;
+
 gboolean
 session_die (GnomeClient *client, gpointer client_data)
 {

@@ -74,7 +76,8 @@
 		if (strcmp (arg, "-?") == 0) {
 			g_printerr ("Usage: %s [--debug]\n", argv[0]);
 			return 0;
-		}
+		} else if (strcmp (arg, "--debug") == 0)
+			debug = 1;
       
 		++i;
 	}

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

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.

Yes.

Exactly.

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.

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?

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I use "hotplug" very broadly ... the /sbin/hotplug infrastructure is how one part of it gets implemented, but isn't the whole story. So (a) and (b) are part of it, but so are many other things.

I'd say both (a) and (b) are subsets of "kernel hotplug", which is limited to delivering events through /sbin/hotplug. We've been enlarging the number of event types the kernel supports, past the original core of USB, PCI, and network events; yet it's still the same simple "typed event" mechanism, no matter how many event types and sources use it.

But if I plug a printer in to my computer, I want it to "hotplug" so that it's automatically hooked into the printing system and appears in the next printer selection dialog I pop up. (And some business customers will demand centralized policy hooks, so printer sharing is appropriately controlled.)

To put it differently: hotplug is just one entree into the system administration toolset. Netlink is another one, more specialized.

- 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

Yes, /sbin/hotplug is that minimal hook for now; though nothing prevents faster event delivery schemes, should they ever really be needed. (*)

From what you say, it seems that someone could whip up a
shell script giving us a hotplug-to-DBus gateway, by using that "dbus-send" program (not in dbus-0.9?) to deliver a hotplug event like:

Header:
name "org.kernel.hotplug.Kernel.Event" srvc ... goes to how many listeners? ... sndr ... whatever kernel authenticates itself as ...

Arguments
uint64 - timestamp
string - argv [0]
string - argv [1]
...
nil
string - envp [0]
string - envp [1]
...
nil

I'd really like to see someone send by such a script, perhaps an "/etc/hotplug/input.agent" to forward input hotplug events so that an X11-ish component can at least monitor keyboards, wheels, drum kits, and such as they appear/disappear.

Eventually of course, that component should make many of those devices available as X11 input devices... :)

- Dave

(*) I can imagine some kernel switch controlling how the hotplug
event gets formatted and delivered. One option would be to spawn a process, as we've done so far. Another would be to queue the events so some process could read them out in the appropriate format. I'd not be surprised to find people needing that second option by the time 2.7 starts.

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

Yeah it's probably post-0.9; you could grab it from anoncvs though.

broadcast I think. (there will be a way in dbus for clients to indicate which broadcasts they want, so a broadcast doesn't wake up every process on the bus - so message senders typically don't need to worry about who gets the message)

sndr is filled in by the bus itself with the connection's base service name, which is an automatically assigned unique ID.

I need to add a 64-bit type, haven't done that yet. It's in TODO though and trivial.

Here you probably want to use array of array of byte - using the array type instead of variable number of args means the message can map to a function call or callback, and using array of byte instead of string means it's binary clean (dbus string type is UTF-8).

Havoc

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

Printers and XFree86 both introduce the idea that some drivers are in userspace. Some "drivers" are even network connections to remote printers...

A device abstraction library would need to think through how to present this to the desktop/application layer.

Havoc

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

Yep, thanks.

Bah, that's just details. ;-)

Havoc

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