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

Isaac Dunham ibid.ag at gmail.com
Sat Mar 14 07:10:27 UTC 2015


On Fri, Mar 13, 2015 at 08:23:49AM +0100, Natanael Copa wrote:
> On Thu, 12 Mar 2015 22:38:10 +0100
> Harald Becker <ralda at gmx.de> wrote:
<snip>
> > So my question to this:
> > 
> > What is the sense of this?
> > What do you want to express with this?
> 
> Show with an example the idea a possible way to solve the hotplug
> forkbomb problem with a minimal long lived netlink listener + short
> lived event handler.
> 
> Instead of just using words to tell how to make a, express it with
> example code.
> 
> > What was your intention to do that code hacking?
> 
> To show that a long-lived netlink daemon can be very small and simple -
> probably much smaller than a fifo manager would be.
> 
> If someone have a better idea how to solve it, I would love to hear it.
> (No, I don't fifos will make it smaller/simpler)

Well, this evening I wrote a knockoff of the short-lived fifo hotplugger
I mentioned (sort of a cross between the netlink hotplugger Nataneal
Copa mentioned as probably being impossible to do right and the FIFO daemon
and hotplugger that Harald Becker was mentioning).

It takes about 120 lines, total.
Most of that is probably the attempts to retry.

Having never written anything with signal, poll, atexit, or fifos before,
I probably left quite a few holes in it.

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

If it isn't the daemon, it dumps the environment into the fifo and re-runs
itself if it gets a SIGPIPE (so that if you dump the environment after the
parser dies, it will retry).

If you set up a fifo supervisor separately, this will let it manage the fifo.

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.

Thanks,
Isaac Dunham
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shp.c
Type: text/x-csrc
Size: 2249 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20150314/759403b9/attachment.c>


More information about the busybox mailing list