RFD: Rework/extending functionality of mdev

[Harald Becker]

Hi Michael !

On 11.03.2015 22:44, Michael Conrad wrote:
> I'm interested in this thread, but there is too much to read.  Can you
> explain your reason in one concise paragraph?

One paragraph is a bit to short, my English sucks, but I try to 
summarize the intention of my approach in compact steps (a bit more than 
one screen page of text):

- current kernel hotplug based mdev suffers from parallel start and 
reading / scanning the conf on each instance

- the known and proven solution to this is using a netlink reader daemon 
(long lived daemon which stays active all the time)

- there are still people who insist staying on the kernel hotplug 
feature (for whatever reason, so accept we need hotplug + netlink)

- The third method (scanning sys file system) is the operation of "mdev 
-s" (initial population of device file system, don't mix with "mdev" w/o 
parameters), in addition some user take this as semi automatic device 
management (embedded world)

- So how can we have all three methods without duplication of code, plus 
how can we speed up the kernel hotplug method?

- answer is to split the gathering parts from the conf file parser and 
device operation, plus let the parser / handler accept many events with 
one invocation (event bursts), plus saving memory when event system is 
idle (parser process exits when idle for some duration)

- kernel hotplug helper could fire up the fifo and a parser / handler 
when there is one required, but this check adds extra delay / cost on 
first / all delivered events

- solution is a minimalistic fifo watcher and parser startup daemon 
(proven Unix concept for on demand N to 1 inter process communication), 
the fifo watcher creates and hold the fifo open, but never touches data 
in the fifo, only startup a parser when required, allows failure 
management when parser sucks

- now the system maintainer can decide which method to use, unwanted 
methods may be opted out on BB config, plus easier embedding BB based 
device management from external programs (include parser, drop methods)

- beside the netlink code, after rework I expect a near 1 : 1 average of 
binary size compared to current code, but less memory usage on event 
bursts (only one parser process), plus speed improvement on event bursts 
(faster system start up when using hotplug)

- other intended functional improvements are for personal preference to 
get the ability of a one-shot device file system startup (single command 
to setup all device stuff, still under full control of admin, no hard 
coded functionality in any binary)

And last: Don't stick on the "mdev -..." names mentioned, look at the 
intended functionalities, implementation details (names to use) are 
still under discussion.

Hope that was short enough.

--
Harald