RFD: Rework/extending functionality of mdev
Natanael Copa
ncopa at alpinelinux.org
Fri Mar 13 08:18:53 UTC 2015
On Thu, 12 Mar 2015 17:31:36 +0100
Harald Becker <ralda at gmx.de> wrote:
> >> 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).
What I meant was that reader needs to reopen it too.
> > 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).
and connect the parser to the fifo?
my point is that you need a minimalist daemon that is always there. Why
not let that daemon listen on netlink events instead?
Since it is so simple as you say, why not write a short demo code?
May help me understand what you really mean.
-nc
More information about the busybox
mailing list