From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 10 Mar 2004 17:52:59 +0000 Subject: Re: udev and dbus Message-Id: <1078941179.1129.30.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 Wed, 2004-03-10 at 17:31, David Zeuthen wrote: > 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. How will you know what file is created? > 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. Sounds fragile, we multiplex with datagrams and fork in the background to get the SIGCHLDS later. I don't think you can send anything like a dbus-message without blocking the whole thing to dead. > 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. Sure, you can specify a whole directory in udev.conf (man udev). Hmm, don't know what's the best... 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