From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sat, 26 Feb 2005 14:00:24 +0000 Subject: Re: event sequencing Message-Id: <1109426425.7400.74.camel@localhost.localdomain> List-Id: References: <9e473391050225081838f673c7@mail.gmail.com> In-Reply-To: <9e473391050225081838f673c7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote: >I working on adding hotplug monitor change detection code to some >framebuffer drivers. I having trouble with event sequencing. Oh, back to the original question and sorry for all that noise. :) >In my probe function I do a class_simple_device_add() to create the >class entry. Later in the probe function I do >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a >monitor change. > >I'm receiving the MOUNT event before the ADD one. How can I control the order? > >Even in cases where MOUNT comes after ADD udev has not built my device >nodes yet. My MOUNT app needs to use the device node. This is my >bigger problem. The event for the fb device needs to create a device node and therefore takes longer than the mount event which seems to happen at the same time. That's the reason for the unpredictable order, which can happen anytime with "normal" hotplug. But all events sent through the kobject_hotplug have kernel created sequence numbers and udevd reorders the events to be executed in the right order. All events belonging to a device will be executed one after the other if udevd recognizes a dependency, which is: the same devpath, a parent device or a physical device behind it. To solve all known kind of timing problems, we changed udev to be able to take over the whole hotplug event and give the "normal" hotplug scripts the same sane timing we need to have for udev to work properly. udev versions later than 047 recognize if /proc/sys/kernel/hotplug is set to /sbin/udevsend and then handle the hotplug scripts too. > I'm using RH FC3 but this needs to work on all distributions when finished. Fedora-Devel has already switched to "managed hotplug events" and the whole system depends on udevd to handle hotplug.d/. Your should not see this problem there. 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://ads.osdn.com/?ad_ide95&alloc_id396&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