RFD: Rework/extending functionality of mdev

Harald Becker ralda at gmx.de
Fri Mar 13 09:41:56 UTC 2015


On 13.03.2015 09:18, Natanael Copa wrote:
>> 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.

What?


> my point is that you need a minimalist daemon that is always there. Why
> not let that daemon listen on netlink events instead?

... because then you need to duplicate the process fire up code in the 
kernel hotplug helper, which adds extra cost to this process, which 
should be as fast as possible. A named pipe (fifo) on the other side, 
allows the helper just to do a simple open to get access to the pipe.


> Since it is so simple as you say, why not write a short demo code?

... because I hate unnecessary code hacking before finishing the planing 
step!

... and what short demo code you are expecting? For what? Showing that a 
thousand times proven concept will work? Examples for using named pipes 
exist already, search on the net, when you like.


> May help me understand what you really mean.

Sorry, that thinking in code is not my way!

I prefer thinking in functionalities and data flows (the way our 
teachers told), and then hop on the build environment, and see what I 
need to do to get the required functionalities (for C / Linux I know 
them, for others I need to dig a bit more, e.g. different language, 
different system). That way, I'm independent of a specific language / 
compiler / environment, and can early change required algorithms without 
much cost, when required.




More information about the busybox mailing list