On 16.03.2015 10:15, Didier Kryn wrote:
4) 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)
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).
This would make the fifosvd specific to the netlink / hotplug function.
My intention is, to get a general usable tool.
You won't gain something otherwise, as the startup of the daemon has to
be done nevertheless. It does not matter if you start fifosvd, and then
it forks again bringing it into background, and then fork again to start
the netlink part, or do it slight different, start an inital code
snipped, that do the pipe creation and the forks (starting the daemons
in background), then step away. This is same operation only moved a bit
around, but may be not blocking other usages.
The netlink reader is a long lived daemon. It shall not exit, and handle
failures internally where possible, but if it fails, pure restarting
without intervening other action to control / correct the failure
reason, doesn't look as a good choice. So it needs any higher instance
to handle this, normally init or a different system supervisor program
(e.g. inittab respawn action).
Where as the device operation handler (including conf parser) is started
on demand, when incoming events require this. The job of the fifosvd is
this on demand pipe handling, including failure management.
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.
Dit you look at my pseudo code? It does *not* use a named pipe (fifo)
for netlink operation, but a normal private pipe (so pipesvd may fit
better it's purpose). Where as hotplug helper mechanism won't work this
way, and require a named pipe (different setup, by just doing slight
different startup).
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.
???
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
