RFD: Rework/extending functionality of mdev

[Didier Kryn]

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