[RFC] Proof-of-concept for netlink listener for mdev -i

Harald Becker ralda at gmx.de
Sun Mar 15 01:30:33 UTC 2015


Hi Isaac !

On 14.03.2015 08:10, Isaac Dunham wrote:
> Basic concept is that it creates a fifo, and treats the success of mkfifo
> as a lock to determine whether it's the daemon or a writer.
> If it's the daemon, it will
> fork;
> in the child:
> 	exec the parser with the fifo as stdin
> in the parent:
> 	set a SIGCHLD handler that respawns the parser if the fifo is not empty,
> 	open the fifo to write,
> 	dump the environment into the fifo
> 	sleep

Congratulations, you implemented the base functionality, I intended, 
except I use some command line parameter to distinguished between 
hotplug helper and parser. This is mainly for increased stability and 
flexibility with no extra cost (due to BB startup / option handling less 
code than fifo check).

... beside not (yet) implemented failure management

... has your approach a problem: The write side of the pipe (fifo) is 
closed as soon as you exit the hotplug helper, which let the parser die 
immediately too (except other hotplug run at exactly the same moment). 
This way you get extra parser starts when events have slight delays. 
With the possibility of race conditions (which need complicated failure 
check and handling).

Therefore it's better to let a small process hold the fifo open and 
available (skips need to recreate on every event). For no extra cost 
this process can do the parser startup, signal management and failure 
checks, as this automatically shares code otherwise also required in the 
netlink part.

... and you got my "fifo manager".


> While I don't think this approach should replace mdev, or that a long-running
> fifo supervisor is a *good* solution for hotplug, it would certainly be
> possible to do what Harald proposes - likely in 200-300 LOC.

So you don't think using a supervisor daemon like tcpsvd is a good 
solution for waiting to incoming network requests? The intended "fifo 
manager" does exactly this, it waits for incoming plug events and fire 
up a plug service handler. ... What is wrong on this solution?

If we put the "fifo manager" into its own applet and call it fifosvd 
giving the specific names on the command line, we get a general "fifo 
supervisor" which may be used for several different IPC operations, 
mainly when using shell script driven Busybox based system operation.

--
Harald



More information about the busybox mailing list