From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 11 Mar 2004 17:14:13 +0000 Subject: Re: udev and dbus Message-Id: <1079025253.1127.111.camel@pim> List-Id: References: <20040217214449.GB12411@wonderland.linux.it> In-Reply-To: <20040217214449.GB12411@wonderland.linux.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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_id70&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