mdev race conditions

[Denys Vlasenko]

On Tuesday 03 June 2008 18:14, Bernard Blackham wrote:
> Mike Frysinger wrote:
> > On Tuesday 03 June 2008, Bernard Blackham wrote:
> >> When I switched from udev+udevd to mdev, booting was much faster and it
> >> shaved a decent amount from the total image size. However, I've recently
> >> noticed device nodes sometimes disappearing on boot.
> > 
> > this is a known corner case and will always be there.  it's why the kernel 
> > guys have deprecated the hotplug exec mechanism in favor of netlink sockets.  
> > the only real solution is a daemon + netlink.  neither of which are desirable 
> > in mdev.  everything else is a workaround.  
> 
> Ah k. Thanks for clearing that up :)
> 
>  > feel free to contribute a mdevd ;).
> 
> Having glanced through udevd.c, I'm rapidly reaching the conclusion that 
> for busybox, a simple mdevd that did the following would suffice:
> 
>   - listen for an event on netlink
>   - when an event arrives, dispatch it to udev (internally even, without
>     forking)
>   - wait for completion (queue up other incoming messages if waiting for
>     an external program)
>   - lather, rinse, repeat
> 
> No control interface, no event queuing, no process throttling, etc.
> 
> There's a lot of extra complexity in udevd - e.g. using a queue 
> mechanism which I gather is to support parallel runs of udev when they 
> can be accomodated. If this, along with the control interface were to be 
> dropped (kill -9 is a control interface to me ;) then I imagine the 
> resulting mdevd would be pretty simple, very small and just as functional.
> 
> Would this be all it takes? Anyone with more than half an hour's 
> experience of looking at udev's source code willing to comment? :)

Didn't look at udev yet.

What about just storing current seq # in a file, and if you see wrong
number in that file, just want for correct one to appear (or time out
in "reasonable time")?
--
vda