From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sat, 13 Mar 2004 18:29:05 +0000 Subject: Re: udev and dbus Message-Id: <1079202500.1783.16.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 Sat, 2004-03-13 at 16:22 +0100, David Zeuthen wrote: > On Fri, 2004-03-12 at 17:40, Daniel Stekloff wrote: > > Hi, I'm curious - are the projects higher in the stack like hal only concerned > > with those devices named by udev? Or, are they interested in all system > > devices? The two sets aren't the same, udev is only concerned with a subset > > of system devices and doesn't manage or name all devices represented in /sys. > > I'd imagine that hal would be interested in all devices reported through /sys > > and if this is the case, shouldn't those projects then place their scripts in > > /etc/hotplug.d? > > > > hal does care about bus devices (e.g. non-class devices like USB, PCI > etc.) and hal does install a symlink, hal.hotplug, in > /etc/hotplug.d/default to catch these and fire off messages to the hal > daemon. > > Now, the problem today is that this script is invoked before > udev.hotplug, because, I guess, h is before u. > > What I want to do is to symlink another script into /etc/udev.d to fire > off a message to the hal daemon. That would give me two scripts, not > just one, which is fine and nice. What is the nice part of two scripts, when you can live with one? > The alternative Kay is suggesting isn't necessarily nice; I would invoke > udevinfo from hal.hotplug but I would have to apply some intelligence > because not every hotplug event corresponds to udev creating/removing > device nodes. Only if you need any info from the udevdb you _may_ ask for it with udevinfo. The creation an removal of the dynamic nodes are only the first part of a hotplug handling sequence, not a magic stack inside of any complex event logic. The kernel notifies you about a new device to use in _userspace_. So it's natural to create the "gate" to this device first. Nobody needs to know who creates the device nodes. And why put one script in some magic udev.d/ script engine and the other in the hotplug.d/ script machinery? What exactly is the problem to execute udevsend as the first program and all following scripts can be sure to have all attribute and nodes created? udev is so fast that you will not notice it, and every hotplug event for a different devpth will run in parallel. > Hotplug events and device node creation/destruction are > two conceptually different things and they should have separate > directories for callouts. There are _a_ sequence, not different things. I still strongly disagree. 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