* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
@ 2003-04-08 5:20 ` Greg KH
2003-04-17 23:50 ` David Brownell
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2003-04-08 5:20 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
2003-04-08 5:20 ` Greg KH
@ 2003-04-17 23:50 ` David Brownell
2003-04-18 0:13 ` David Brownell
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: David Brownell @ 2003-04-17 23:50 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
2003-04-08 5:20 ` Greg KH
2003-04-17 23:50 ` David Brownell
@ 2003-04-18 0:13 ` David Brownell
2003-04-18 5:39 ` Havoc Pennington
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: David Brownell @ 2003-04-18 0:13 UTC (permalink / raw)
To: linux-hotplug
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (2 preceding siblings ...)
2003-04-18 0:13 ` David Brownell
@ 2003-04-18 5:39 ` Havoc Pennington
2003-04-18 5:51 ` Havoc Pennington
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Havoc Pennington @ 2003-04-18 5:39 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (3 preceding siblings ...)
2003-04-18 5:39 ` Havoc Pennington
@ 2003-04-18 5:51 ` Havoc Pennington
2003-04-18 22:40 ` Greg KH
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Havoc Pennington @ 2003-04-18 5:51 UTC (permalink / raw)
To: linux-hotplug
[-- 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;
}
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (4 preceding siblings ...)
2003-04-18 5:51 ` Havoc Pennington
@ 2003-04-18 22:40 ` Greg KH
2003-04-18 23:45 ` David Brownell
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2003-04-18 22:40 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (5 preceding siblings ...)
2003-04-18 22:40 ` Greg KH
@ 2003-04-18 23:45 ` David Brownell
2003-04-19 0:49 ` David Brownell
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: David Brownell @ 2003-04-18 23:45 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (6 preceding siblings ...)
2003-04-18 23:45 ` David Brownell
@ 2003-04-19 0:49 ` David Brownell
2003-04-19 1:24 ` Havoc Pennington
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: David Brownell @ 2003-04-19 0:49 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (7 preceding siblings ...)
2003-04-19 0:49 ` David Brownell
@ 2003-04-19 1:24 ` Havoc Pennington
2003-04-19 1:30 ` Havoc Pennington
2003-04-19 1:43 ` Havoc Pennington
10 siblings, 0 replies; 12+ messages in thread
From: Havoc Pennington @ 2003-04-19 1:24 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (8 preceding siblings ...)
2003-04-19 1:24 ` Havoc Pennington
@ 2003-04-19 1:30 ` Havoc Pennington
2003-04-19 1:43 ` Havoc Pennington
10 siblings, 0 replies; 12+ messages in thread
From: Havoc Pennington @ 2003-04-19 1:30 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: communicating with user login sessions
2003-04-08 4:37 communicating with user login sessions Havoc Pennington
` (9 preceding siblings ...)
2003-04-19 1:30 ` Havoc Pennington
@ 2003-04-19 1:43 ` Havoc Pennington
10 siblings, 0 replies; 12+ messages in thread
From: Havoc Pennington @ 2003-04-19 1:43 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 12+ messages in thread