communicating with user login sessions

communicating with user login sessions

[Havoc Pennington]

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

Re: communicating with user login sessions

[Greg KH]

On Tue, Apr 08, 2003 at 12:37:44AM -0400, Havoc Pennington wrote:
> 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/

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

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

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

Re: communicating with user login sessions

[David Brownell]

Havoc Pennington wrote:
> 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.

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.


> 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"
> ...
>   http://www.freedesktop.org/software/dbus/

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

Re: communicating with user login sessions

[David Brownell]

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

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

Re: communicating with user login sessions

[Havoc Pennington]

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

Re: communicating with user login sessions

[Havoc Pennington]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On Thu, Apr 17, 2003 at 04:50:14PM -0700, David Brownell wrote: 
> 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 ...

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



[-- Attachment #2: cups-dbus.patch --]
[-- Type: text/plain, Size: 3100 bytes --]

--- cups-1.1.18/scheduler/main.c.dbus	2003-04-12 19:32:53.000000000 -0400
+++ cups-1.1.18/scheduler/main.c	2003-04-12 19:41:35.000000000 -0400
@@ -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.
--- cups-1.1.18/scheduler/cupsd.h.dbus	2002-12-17 14:00:15.000000000 -0500
+++ cups-1.1.18/scheduler/cupsd.h	2003-04-12 19:32:53.000000000 -0400
@@ -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 $".
--- cups-1.1.18/scheduler/Makefile.dbus	2002-12-17 14:00:12.000000000 -0500
+++ cups-1.1.18/scheduler/Makefile	2003-04-12 19:32:53.000000000 -0400
@@ -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)
 
 
 #
--- cups-1.1.18/scheduler/job.c.dbus	2002-12-17 14:00:16.000000000 -0500
+++ cups-1.1.18/scheduler/job.c	2003-04-12 19:32:53.000000000 -0400
@@ -108,6 +108,7 @@
   else
     Jobs = job;
 
+  dbus_broadcast ();
   return (job);
 }
 
@@ -201,8 +202,11 @@
 	NumJobs --;
       }
 
+      dbus_broadcast ();
       return;
     }
+
+  dbus_broadcast ();
 }
 
 

[-- Attachment #3: eggcups-0.0.2-dbus.patch --]
[-- Type: text/plain, Size: 4552 bytes --]

--- desktop-printing-0.1.10/eggcups-0.0.2/configure.in.dbus	2003-04-13 00:45:16.000000000 -0400
+++ desktop-printing-0.1.10/eggcups-0.0.2/configure.in	2003-04-13 00:45:16.000000000 -0400
@@ -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)
--- desktop-printing-0.1.10/eggcups-0.0.2/main.c.dbus	2002-12-08 05:04:44.000000000 -0500
+++ desktop-printing-0.1.10/eggcups-0.0.2/main.c	2003-04-13 00:45:16.000000000 -0400
@@ -2,7 +2,7 @@
 /*
  * Copyright (C) 2002 CodeFactory AB
  * Copyright (C) 2002 Richard Hult <rhult@codefactory.se>
- * Copyright (C) 2002 Tim Waugh <twaugh@redhat.com>
+ * Copyright (C) 2002, 2003 Tim Waugh <twaugh@redhat.com>
  *
  * 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;
 	}
--- desktop-printing-0.1.10/eggcups-0.0.2/lpegg.c.dbus	2002-12-08 06:55:27.000000000 -0500
+++ desktop-printing-0.1.10/eggcups-0.0.2/lpegg.c	2003-04-13 01:08:20.000000000 -0400
@@ -2,7 +2,7 @@
 /*
  * Copyright (C) 2002 CodeFactory AB
  * Copyright (C) 2002 Richard Hult <rhult@codefactory.se>
- * Copyright (C) 2002 Tim Waugh <twaugh@redhat.com>
+ * Copyright (C) 2002, 2003 Tim Waugh <twaugh@redhat.com>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -33,12 +33,18 @@
 #include <gdk/gdkkeysyms.h>
 #include <gtk/gtk.h>
 #include <libgnomeui/gnome-stock-icons.h>
+#include <dbus/dbus-glib.h>
 #include "eggtrayicon.h"
 #include "lp-intl.h"
 #include "lpcups.h"
 #include "lpegg.h"
 
+#include <stdio.h>
+
 struct _LpEgg {
+	/* D-BUS */
+	DBusConnection *dbus;
+
 	/* Widgets. */
 	EggTrayIcon   *icon;
 	GtkWidget     *icon_image;
@@ -51,6 +57,8 @@
 	GtkItemFactory *popup_factory;
 	GtkTooltips *tips;
 	gchar *tip;
+
+	unsigned int timer;
 };
 
 static void
@@ -144,6 +152,61 @@
 
 extern gboolean debug;
 
+static gboolean maybe_change_state (LpEgg *lp);
+
+static DBusHandlerResult
+handle_dbus_message (DBusMessageHandler *handler,
+		     DBusConnection *connection,
+		     DBusMessage *message,
+		     void *data)
+{
+	LpEgg *lp = (LpEgg *) data;
+	if (debug) printf ("eggcups: Received message: %s\n",
+			   dbus_message_get_name (message));
+	if (dbus_message_name_is (message, DBUS_MESSAGE_LOCAL_DISCONNECT)) {
+		/* Fall back to polling. */
+		if (debug) puts ("eggcups: Falling back to polling..");
+		lp->dbus = NULL;
+		dbus_connection_unref (connection);
+ 		lp->timer = g_timeout_add (5000,
+					   (GSourceFunc) maybe_change_state,
+					   lp);
+	} else if (dbus_message_name_is (message, "com.redhat.PrinterSpooler.QueueChanged"))
+		maybe_change_state (lp);
+
+	return DBUS_HANDLER_RESULT_ALLOW_MORE_HANDLERS;
+}
+
+static void leak (void *nothing) { }
+
+static int
+init_dbus (LpEgg *lp)
+{
+	DBusMessageHandler *handler;
+	DBusConnection *dbus;
+	DBusError error;
+	DBusMessage *message, *reply;
+
+	lp->dbus = NULL;
+	dbus_error_init (&error);
+	dbus = dbus_bus_get (DBUS_BUS_SYSTEM, &error);
+	if (dbus == NULL) {
+		if (debug) printf ("eggcups: %s\n", error.message);
+		dbus_error_free (&error);
+		return -1;
+	}
+
+	/* FIXME "handler" is leaked if we later unref the connection.
+	 * (the way this works may change in libdbus, it's kind
+	 * of annoying) - hp
+	 */
+	handler = dbus_message_handler_new (handle_dbus_message, lp, leak);
+	dbus_connection_add_filter (dbus, handler);
+	dbus_connection_setup_with_g_main (dbus);
+	lp->dbus = dbus;
+	return 0;
+}
+
 static gboolean
 maybe_change_state (LpEgg *lp)
 {
@@ -176,6 +239,12 @@
 	} else
 		g_free (tip);
 
+	/* Try to connect to the system D-BUS */
+	if (lp->timer != -1 && !lp->dbus) {
+		if (!init_dbus (lp))
+			g_source_remove (lp->timer);
+	}
+
 	return TRUE;
 }
 
@@ -335,11 +404,14 @@
 			  G_CALLBACK (icon_destroy_cb),
 			  lp);
 
+	lp->timer = -1;
 	maybe_change_state (lp);
 
-	g_timeout_add (5000,
-		       (GSourceFunc) maybe_change_state,
-		       lp);
+	if (init_dbus (lp))
+		/* Fall back to polling. */
+ 		lp->timer = g_timeout_add (5000,
+					   (GSourceFunc) maybe_change_state,
+					   lp);
 
 	return lp;
 }

Re: communicating with user login sessions

[Greg KH]

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

Re: communicating with user login sessions

[David Brownell]

Greg KH wrote:

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

Re: communicating with user login sessions

[David Brownell]

Havoc Pennington wrote:
> 
> 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.

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

Re: communicating with user login sessions

[Havoc Pennington]

On Fri, Apr 18, 2003 at 05:49:56PM -0700, David Brownell wrote: 
>  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?) 

Yeah it's probably post-0.9; you could grab it from anoncvs though.
 
>        Header:
>            name "org.kernel.hotplug.Kernel.Event"
>            srvc ... goes to how many listeners? ...

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 ... whatever kernel authenticates itself as ...

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

>        Arguments
>            uint64 - timestamp

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

>            string - argv [0]
>            string - argv [1]

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

Re: communicating with user login sessions

[Havoc Pennington]

On Fri, Apr 18, 2003 at 04:45:11PM -0700, David Brownell wrote: 
> 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.)

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

Re: communicating with user login sessions

[Havoc Pennington]

On Fri, Apr 18, 2003 at 03:40:08PM -0700, Greg KH wrote: 
> 
> Does that help out?

Yep, thanks.

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

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