On 13.03.2015 21:32, Michael Conrad wrote:
Are you suggesting even the netlink mode will have a process reading the
netlink socket and writing the fifo, so another process and can process
the fifo? The netlink messages are already a simple protocol, just use
it as-is. Pass the
You got the function of the fifo manager (or supervisor) wrong. This
little process does never read or touch the fifo data, it's purpose is
to fire up the parser (pipe consumer) when any gathering part as written
something into the pipe and there is no running parser process. In
addition this supervisor may spawn a failure_script, when the parser
abort unexpectedly.
Have you ever used tcpsvd ?
This piece open a network socket, then accept incoming connections and
pass the socket to a spawned service process.
The fifo manager does the same for the named pipe.
The data flow is:
netlink daemon -> pipe -> parser
or
hotplug helper -> pipe -> parser
The new code behaves exactly as the old code. When used as a hotplug
helper, it suffers from parsing conf for each event. My approach is a
splitting of the old mdev into two active threads, which avoid those
problems even for those who like to stay at kernel hotplug.
Then it sounds like indeed, you are introducing new configuration steps
for the old-style hotplug helper?
?
i.e. where does the fifo live?
at a simple default: /dev/.xdev-pipe, because any reading of such
parameters in the hotplug helper would slow down the operation. Remember
hotplug helpers a spawned in parallel.
who owns it?
The only user who's allowed to do netlink operation, load modules,
create any device nodes, etc. -> root:root
what security implications does this have?
Mode of the fifo will be 0600 = rw-------
Who starts the single back-end mdev processor?
This is the job of the fifo manager (or named pipe supervisor). The
processor, as you call it, is started on demand, when data is written to
the fifo, the processor has to die when when idle for some time.
If started from the hotplug-helper, who ensures that only one gets started?
? started from the hotplug helper? the helper won't ever start anything,
just:
hotplug helper:
gather event information
sanitize message
open named pipe for writing
(ok, if this open fails seriously, we are in big trouble)
(true for many other such operations)
(to be discussed what's best failure handling for this)
if pipe is open, (safe) write the event message
(the safe means, in loop and checking for success)
exit 0
netlink reader:
open named pipe
(for failures here have already added an option)
(will spawn a given script with failure reason)
(or otherwise retries some times, then die)
open netlink socket
in an endless loop
wait for messages arriving
sanitize message
(safe) write the event message into the pipe
fifosvd:
create named pipe (fifo)
open fifo for reading and writing in none blocking mode
in an endless loop
wait for data arriving in pipe (poll)
spawn the parser process redirecting stdin from fifo
wait for exit of the spawned process
if not exited successfully
spawn the given failure script with arguments
if failure script exits unsuccessful, then die
parser:
read conf file into memory table
while read next message from stdin with timeout
sanity checks of message (paranoia)
lookup device entry in memory table
do required operation for the message
Is this better for you?
I really hate code hacking before I'm able to finish planing.
If people have existing systems using hotplug-helper mdev, you can't
just change the implementation on them in a way that requires extra
configuration.
Which extra configuration?
Everyone who has commented on this thread so far agrees with that.
You definitely misunderstand my approach and how it works!
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
