From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 11 Mar 2004 02:35:19 +0000 Subject: Re: udev and dbus Message-Id: <1078972519.2582.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 Wed, 2004-03-10 at 23:48, Greg KH wrote: > On Wed, Mar 10, 2004 at 02:25:27PM -0800, Patrick Mansfield wrote: > > On Wed, Mar 10, 2004 at 11:18:06AM -0800, Greg KH wrote: > > > On Wed, Mar 10, 2004 at 05:31:09PM +0100, David Zeuthen wrote: > > > > > > > > 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. > > > > > > > > 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) > > > > > > Yes, that is abusing the hotplug multiplexor. I don't like it :) > > > > I like it. Why does the kernel get to abuse it but not user space ;-) > > > > Then dbus or anyone can create an agent. And those wanting to > > automatically mount devices, start applications, or setup dm have a nice > > place to put their scripts. In a initrd/initramfs, you could even mount > > and start init based on the root device showing up. > > > > We should have a simple "your /dev/foo has arrived" interface. > > 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 :) > > 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... > But it would solve the org.kernel namespace issues for DBUS, right? I prefer changing dbus to be able to receive messages from multiple senders with the same origin at the same time. What about sending dbus-messages with udev, depending on a environment variable. If called by udevd and we can toggle the state of the environment variable udevd passes down. So after dbus is able to receive, it can toggle on the switch for udev to send? 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