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