From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 09 Dec 2004 08:18:28 +0000 Subject: Re: udevd: serialize device chain event sequence Message-Id: <1102580308.10393.14.camel@localhost.localdomain> List-Id: References: <20041208231335.GA6402@vrfy.org> In-Reply-To: <20041208231335.GA6402@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote: > On Wednesday 08 December 2004 3:13 pm, Kay Sievers wrote: > > Any objections against the serialization of the event sequence of a > > chain of devices. Currently udevd delays only events for the same > > DEVPATH. > > I'm amused ... that's what the original hotplug code achieved. > Thing is, now serialization would be done in userspace, rather > than offering new and fun paths to kernel deadlock nirvana! :) Yeah, the same applies to current userspace code, like the one we have in HAL :) > > Example of an "add" event sequence: > > /block/sda > > /block/sda/sda1 > > > > With this change, we make sure, that the udev process handling /block/sda > > has finished its work (waited for all attributes, created the node) before > > we fork the udev event for /block/sda/sda1. This way the event for sda1 can > > be sure, that the node for the main device is already created (may be > > useful for disk labels). > > But the "add" for the underlying hardware (maybe USB) would > not be serialized. Right, just the stream of events for the /sys/devices/-device is serialized, but in another event sequence. The class/block device carries from kernel 2.6.10+ on the PHYSDEVPATH variable in the environment, which makes it easy to know what to wait for. > > The main motivation to do this is the program execution of the dev.d/ > > and hotplug.d/ directory. If we don't wait for the parent event to exit, > > we can't be sure that the executed scripts are run in the right order. > > Could that argument apply to the underlying hardware, too? Good question. I never thought about that until you asked. :) It sounds nice to let udevd serialize the complete event stream, based on PHYSDEVPATH. I will try it today and come back... Thanks, Kay ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ 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