Kay Sievers wrote:
> On Fri, 2005-01-14 at 11:22 +0100, Hannes Reinecke wrote:
> 
>>Hi all,
>>
>>this patch adds the capabilities to read uevents directly from the 
>>kernel socket (CONFIG_KOBJECT_UEVENT=y).
> 
> 
> Heh, I just split up the message handling in udevd last week to possibly
> plug in a second source of events. Nice work!
> 
> 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?)

> 
>>The old behaviour is left in place, as with this we can still send 
>>events manually.
> 
> 
> ./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 <-

How does this expected event number thingie work?
If we're presetting the expected number, what will happen to events 
which might be fed from udevsend after startup of udevd?
Especially interesting if the udevinitd approach is used ...

> 
>>Now we can do
>>/sbin/udevd -p
> 
> 
> -p? :)
> 
:-)
-ENOCOFFEE

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de