RFD: Rework/extending functionality of mdev

Harald Becker ralda at gmx.de
Sun Mar 15 23:58:16 UTC 2015


We were looking at alternative solutions, so even one more:

3) netlink reader the Unix way

Why let our netlink reader bother about where he sends the event 
messages. Just let him do his netlink receiption job and forward the 
messages to stdout.

netlink reader:
    set stdout to non blocking I/O
    establish netlink socket
    wait for event messages
      gather event information
      write message to stdout

hotplug startup code:
    create a private pipe
    spawn netlink reader, redirect stdout to write end of pipe
    spawn fifosvd - xdev parser, redirect stdin from read end of pipe
    close both pipe ends (write end open in netlink, read in fifosvd)

This way we can let the starting process decide which type of pipe we 
use: private pipe for netlink, and named pipe for hotplug helper.

I think this is not far away from Laurent's (or Natanael's) solution, at 
the only cost of a small long lived helper process, managing the on 
demand handler startup and checking for failures. Small general purpose 
daemon in the sense of supervisor daemons (e.g. tcpsvd), with generally 
reusable function for other purposes.

... better?

Ok, but brings me to the message format in the pipe, I highly think, we 
should use a textual format, but do required checks for control chars 
and do some (shell compatible) quoting.

This would allow to do:

   netlink reader >/dev/ttyX
   (to display all device plug events on a console)

   netlink reader >>/tmp/uevent.log
   (append all event message to log file)

   ... and all such things.

I know, the parser needs to do some checking and unquoting, but we have 
a single reader and it doesn't matter how much data it reads from the 
pipe in a single hunck, as long as the writers assure, they are going to 
write a single message with one write (atomicity). The parser assumes 
reading text from stdin, with required checking and unquoting. This way 
we get maximum compatibility and may easily replace every part with some 
kind of script.

--
Harald

_______________________________________________
busybox mailing list
busybox at busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


More information about the busybox mailing list