RFD: Rework/extending functionality of mdev

[Harald Becker]

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