Hi Natanael !
> I assume that you are talking about named pipes (aka fifos)
http://en.wikipedia.org/wiki/Named_pipe
Ack, fifo device in the Linux / Unix world.
Why do you need a hotplug helper spawned by kernel when you have a
netlink listener? The entire idea with netlink listener is to avoid the
kernel spawned hotplug helper.
... because there are people, wo dislike using netlink and want use the
kernel hotplug helper mechanism. That's it. Peoples preferences are
different. Opt out the functions you dislike in BB config.
... but this is vise versa, for those who chose to use the kernel
hotplug mechanism.
It simply does not make sense to have both.
Both active at the same time? Sure! ... This is not the intention. I've
been talking about the functionalities, which need to be implemented.
Every gathering part grabs the required information, sanitizes,
serializes and then write some kind of command to the fifo. The fifo
management (a minimalist daemon) starts a new parser process when
there is none running and watches it's operation (failure handling).
If you are talking about named pipes (created by mkfifo) then your
"fifo approach" approach will break here.
Once the writing part of the fifo (eg a "gathering part") is done
writing and closes the writing part, the fifo is consumed and needs to
be re-created. no other "gathering part" will be able to write anything
to the fifo.
??? You don't understand operation of named pipes!
Any program (with appropriate rights) may open the "named pipe" (fifo)
for writing. As long as data for one event is written in one big chunk,
it won't interfere with possible parallel writers. If the fifo device is
closed by a writer, this does not mean it vanishes, just reopen for
writing and write next event hunk).
Basically what you describe as a "fifo manager" sounds more like a bus
like dbus.
It is the old and proven inter process communication mechanism of Unix,
nothing new.
And "fifo manager" sounds really big, it is a really minimalistic
daemon, with primitive operation (does never touch the data in the fifo,
nor even read that data). It's main purpose beside creating the fifo, is
to fire up a conf parser / device operation process when required, and
to react on failure of them (spawn a script with args).
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
