From: David Zeuthen <david@fubar.dk>
To: linux-hotplug@vger.kernel.org
Subject: udev and dbus
Date: Wed, 10 Mar 2004 16:31:09 +0000 [thread overview]
Message-ID: <1078936268.1731.45.camel@powerbook.fubar.dk> (raw)
In-Reply-To: <20040217214449.GB12411@wonderland.linux.it>
Hi Greg and Kay,
As far as I can tell there are still issues with the dbus support in
udev due to the fact that udev needs to be available in early boot -
this issue have been raised a few times with little or response.
I'm willing to make a patch to fix it (unless someone beats me to it),
but before I go ahead I'd like some input on how we want it to look
like. I can see at least the following three scenarios:
1. Remove dbus support from udev and make udev call /sbin/hotplug with
a single positional parameter, 'udev', and the environment variables
DEVPATH pointing to the appropriate directory in sysfs, ACTION
assuming 'add' respectively 'remove' and DEVICE_FILE pointing to
the created / removed special device file.
This way, applications, like HAL, interested in the event can simply
install a small program in /etc/hotplug.d/[udev,default] to do
whatever they want with the event, like sending it to a daemon
possibly through what may be the IPC-flavour of the month :-)
(yes, this might be abusing the hotplug multiplexor)
2. Move dbus support from udev to udevd, make sure udevd never
exits, and let udevd own the org.kernel.udev service. I guess
this would imply building two udevd binaries; one with
dbus support and one without (for early boot) and make the small
one load the big one upon receiving SIGUSR1. I think Marco
d'Itri came up with this approach.
I'm not too familiar with udevd, but I seem to recall that it
spawns udev copies to do the work so it may require more tweaking
to do this.
However, using this approach, we can also offer queries on the
udev database using dbus instead of using udevinfo. That would
be nice.
3. Remove dbus support and if applications are interested in sending
out events using IPC like dbus, they just install a udev callout.
I'm not sure this is easy today as all the callout rules are in
a single file instead of a directory with rule files. I may be
wrong on this though.
Of course, there might be other ways of acheiving sending out events
through e.g. dbus, but I can't think of any.
Let me know what you think - I'd really like to resolve this issue.
Take care,
David
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
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
next prev parent reply other threads:[~2004-03-10 16:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-17 21:44 udev and DBUS Marco d'Itri
2004-02-26 17:00 ` Marco d'Itri
2004-02-28 14:13 ` David Zeuthen
2004-03-10 16:31 ` David Zeuthen [this message]
2004-03-10 17:52 ` udev and dbus Kay Sievers
2004-03-10 19:18 ` Greg KH
2004-03-10 19:56 ` Greg KH
2004-03-10 19:57 ` Marco d'Itri
2004-03-10 20:00 ` Marco d'Itri
2004-03-10 20:02 ` Greg KH
2004-03-10 22:25 ` Patrick Mansfield
2004-03-10 22:37 ` Kay Sievers
2004-03-10 22:48 ` Greg KH
2004-03-11 1:28 ` Greg KH
2004-03-11 2:35 ` Kay Sievers
2004-03-11 8:55 ` Martin Waitz
2004-03-11 14:30 ` Kay Sievers
2004-03-11 15:06 ` David Zeuthen
2004-03-11 17:14 ` Kay Sievers
2004-03-11 17:23 ` Kay Sievers
2004-03-11 17:30 ` David Zeuthen
2004-03-11 17:41 ` David Zeuthen
2004-03-11 17:44 ` Kay Sievers
2004-03-11 18:12 ` Kay Sievers
2004-03-11 18:22 ` David Zeuthen
2004-03-11 18:32 ` Greg KH
2004-03-11 18:35 ` Greg KH
2004-03-11 18:36 ` Greg KH
2004-03-11 18:37 ` Kay Sievers
2004-03-11 18:38 ` Kay Sievers
2004-03-11 18:40 ` Kay Sievers
2004-03-11 18:47 ` Greg KH
2004-03-11 18:56 ` Kay Sievers
2004-03-12 0:18 ` Greg KH
2004-03-12 11:37 ` David Zeuthen
2004-03-12 15:54 ` Kay Sievers
2004-03-12 16:40 ` Daniel Stekloff
2004-03-12 17:17 ` Marco d'Itri
2004-03-12 17:26 ` Marco d'Itri
2004-03-13 15:22 ` David Zeuthen
2004-03-13 18:29 ` Kay Sievers
2004-03-14 19:59 ` Olaf Hering
2004-03-14 20:06 ` Kay Sievers
2004-03-14 20:11 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1078936268.1731.45.camel@powerbook.fubar.dk \
--to=david@fubar.dk \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).