Re: udev and dbus

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, 2004-03-11 at 11:48, David Zeuthen wrote:
> On Wed, Mar 10, 2004 at 02:48:16PM -0800, Greg KH wrote:
> > Ok, I have no problem with something like /etc/udev.d/ for when udev is
> > finished creating or removing a device that works the same way that
> > /etc/hotplug.d/ does for kernel hotplug events.  I just would not want
> > to overload the hotplug interface, as that would get quite messy very
> > quickly :)
> > 
> 
> Great, I'll start writing a patch!
> 
> > Then we could drop a udevdbusd program that would catch all of the udev
> > messages and send them to the DBUS.  Heh, layers on top of layers...
> 
> Right - this program udevdbus (shouldn't be a daemon though, yes?) would
> just do what udev did before:
> 
>  1. acquire the org.kernel.udev service from the system bus
>  2. emit a signal with saying this node added/removed
>  3. release the org.kernel.udev service
> 
> Any program can then subscribe to the org.kernel.udev service on the
> system message bus to pickup the signal and do it's thing. 
> 
> Of course the whole point of having the org.kernel.udev service in the 
> first place (in my mind at least) was that it would allow you to do
> fancy things like the queries you use udevinfo for, by only using
> dbus as the IPC. (Hmm, maybe this can even be done through dbus activation
> at some point).
> 
> So, I kind of question the merit of having udevdbus, since applications
> interested in udev events, like HAL, can just install a program to
> 
>  1. connect to the org.foobar.something service
>  2. send a message to that service
>  3. disconnect from the org.foobar.something service
> 
> But I can go ahead and write udevdbus anyway if you want to - conceptually
> it's nice that *any* program can pickup the fact that a new device node
> have been created.

Sorry, but are you guys getting completely crazy? :)

Why you want a stacked hotplug.d/udev.d forking hell or a "serializer"
for the dbus daemon? This is simply unmaintainable and _nobody_ will
understand this. We have enough problems to teach the /sbin/hotplug and
udev/udevsend/udevd logic.

We can rip dbus out and make a external dbus caller, yes that's fine.
But dbus should use the /sbin/hotplug multiplexer. Just get the needed
information with udevinfo and then fire up the dbus-client.

We can also keep udev's dbus-send as it is and just make it switchable.
If dbus is finally running, you can simply switch it on. But yes,
ripping it out seems cleaner.

So, please please remember the goal of udev :)

thanks,
Kay




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