RFD: Rework/extending functionality of mdev

[Harald Becker]

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