From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Fri, 14 Jan 2005 12:11:55 +0000 Subject: Re: [PATCH] use uevents in udevd Message-Id: <1105704715.17412.24.camel@localhost.localdomain> List-Id: References: <41E79D7A.2060607@suse.de> In-Reply-To: <41E79D7A.2060607@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Fri, 2005-01-14 at 12:22 +0100, Hannes Reinecke wrote: > Kay Sievers wrote: > > On Fri, 2005-01-14 at 11:22 +0100, Hannes Reinecke wrote: > > Shouldn't we ignore events with a SEQNUM from udevsend, if we get the > > first one from the uevent? > > > Indeed we should. I fixed the patch accordingly. > (Hopefully correct; the list is scanned backwards, right?) We can't be sure that the message coming in from netlink is still in the queue. I think we should just set a flag with the first valid netlink message we receive and skip all udevsend messages with a SEQNUM set from that on. > > ./drivers/input/input.c > > ./drivers/pnp/pnpbios/core.c > > ./drivers/s390/crypto/z90main.c > > > > are still "broken" from that view. They bypass the driver core and don't > > send any uevent. > > > Oh s**t. Still? > > Time to lean on Vojtech to fix the input layer. > Martin promised that z90main will be fixed, so no worries about that > one. Will have to check pnpbios. > >>And I've added a command-line option '-d' to start udevd as a daemon. > > > > > > It is already running, right? We should read /sys/kernel/hotplug_seqnum > > and initialize the next expected event number too, if the self-daemonize > > is needed. > > > Well, no. At least not necessarily. > And doesn't matter anyway as it will exit if another daemon is already > running. > -> There can be only one <- I mean: Why do you want to start it manually? The fist event will do this normally. But you are right, if one want's to start it, it's better than ./udevd&. > How does this expected event number thingie work? The daemon has a state which event is the next expected. If we get something different from the expected number we will wait until a timeout. If you kill it and restart it or just start it by hand, we have a good chance to set the correct next_expected number from the kernel. > If we're presetting the expected number, what will happen to events > which might be fed from udevsend after startup of udevd? It's slippery yes, but initializing it may be slightly better than not to read it. :) It's not really important anymore as the next version of udev will have a special startup event timout of 2sec. But the current one has a 10sec timeout which e.g. breaks the firmware loader which also has a 10sec timeout. :) > Especially interesting if the udevinitd approach is used ... In this case we need to do more special handling when we receive the queue from initramfs, so we can handle that, right? Thanks, Kay ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ 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