From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 11 Mar 2004 18:12:55 +0000 Subject: Re: udev and dbus Message-Id: <1079028775.1127.149.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 18:41, David Zeuthen wrote: > On Thu, 2004-03-11 at 18:14, Kay Sievers wrote: > > On Thu, 2004-03-11 at 16:06, David Zeuthen wrote: > > > On Thu, 2004-03-11 at 15:30, Kay Sievers wrote: > > 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. > > > > Wearing a purist-hat, I would consider this a bad hack - so you want to > hardcode the requirement that udevinfo needs to run before anything into > whatever hotplug multiplexor is running? Why? If you don't need the node names don't wait for udevsend and don't call udevinfo. > What if I want to write a hotplug multiplexor that runs a number of > programs in parallel in response to a hotplug event? What if I want to > write another implementation of a device node manager to replace udev? > (not that I want to at, I really like udev, but I'm against setting > requirements on how a hotplug multiplexor should work). What do you think of? There are no requirements. If your script rely on the dynamically nodes, you need to wait for udev anyway. If not, just go ahead. > > 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 :) > > No. I'm simply asking that udev executes a program when it add/removes > device nodes, that's all - calling this an arbritary hotplug script > engine is simply not representative of what I ask for. I've said I'm > even willing to write the patch myself :-) I expect lot of lazy people to put their scripts in there, cause it's so comfortable to live inside the serialized hotplug events. Something like this: "Nice, I can mount my USB-stick with udev.d/ right after udev has created my partition node, cause the scsi.agent was too fast..." So I still vote for not doing this. 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