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@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to