Re: udev and dbus

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

On Thu, 2004-03-11 at 16:06, David Zeuthen wrote:
> On Thu, 2004-03-11 at 15:30, Kay Sievers wrote:
> > 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. 
> 
> What's so difficult with understanding that udev calls a series of
> programs in /etc/udev.d when it add/remove device nodes?

Oh, it's not as easy as you might think. Just read this list or
_your_ yesterdays mail, where you propose that udev should call
/sbin/hotplug, which is a nice loop, right :)

> > 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.
> 
> This I would recommend against - not every hotplug event makes udev
> create/remove a device node; networking devices are one example. 

Zero argument! You want udev to call scripts for a device it doesn't
handle itself, with a empty NODES environment? That's definitely nothing
more than misuse of infrastructure.

> Oh, and wouldn't there be a potential race with udev, so you'd need to
> poll with udevinfo until you get the device file from udevinfo?

Just make udevsend wait until the nodes are created (we already have a
patch for it from Chris) and execute udevsend as the first program with
/sbin/hotplug. All the following programs are sure that the nodes on
it's place and can query the node names with udevinfo. Easy, clean, nice
transparent and understandable.

> > 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.
> > 
> 
> As someone mentioned in another mail, you will still have the potential
> problem of the libdbus.so being on /usr which could be a separate
> partition from / and, blam, udev can't run to create the device node for
> the disk that /usr is on. 
> 
> Hence I would argue that it's desirable to keep the code sending the
> dbus event in a binary separate from udev. Do you agree?

Yes, I agree completely.

> > So, please please remember the goal of udev :)
> > 
> 
> I think the proposal is really simple:
> 
>  1. Rip out dbus-sender from udev
>  2. Make udev call all executables in /etc/udev.d
>  3. *optionally* provide a udevdbus program and place it in /etc/udev.d
> 
> and I argue this will udev simpler and not depend on dbus at all, while
> still maintaining the dbus functionality. Oh, and solving the problem
> with 'dbus support is disabled because of...'.

Yes, you are right. I see the problem.

> (For the udevdbus program, we could place this in /usr/libexec and
> symlink it to /etc/udev.d - udev can then, upon traversing /etc/udev.d,
> check if the link is stale or not)

Yes, but with /sbin/hotplug!

> People can even use whatever IPC they may like to use the information
> from udev, write custom shell scripts or whatever.

udev is a device node manager, nothing more. I _strongly_ disagree on
making udev a arbitrary hotplug script engine. Please solve the problem
on it's source not on the first comfortable place :)

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