Le 16/03/2015 00:58, Harald Becker a écrit :
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)
The general scheme makes sense to me, but I would chane two details:
1) why not let fifosvd act as the startup code? It is anyway the
supervisor of processes at both ends of the pipe and in charge of
re-spawning them in case they die. Netlink receiver should be restarted
immediately to not miss events, while event handler should be restarted
on event (see comment below).
2) fifosvd would never close any end of the pipe because it could
need them to re-spawn any of the other processes. Like this, no need for
a named pipe as long as fifosvd lives.
And I have a suggestion for simplicity: Let be the
timeout/no-timeout feature be a parameter only for the event handler; it
does not need to change the behaviour of fifosvd. I think it is fine to
restart event handler on-event even when it dies unexpectedly.
Didier
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
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
