Re: [PATCH] use uevents in udevd

[Kay Sievers <kay.sievers@vrfy.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