RFD: Rework/extending functionality of mdev

[Harald Becker]

Hi Natanael !

 > I am interested in a netlink listener too for 2 reasons:
>
> - serialize the events
> - reduce number of forks for perfomance reasons

My primary intentions.

>> That is, I want to auto fork a daemon which just open the netlink
>> socket. When events arrive it forks again, creating a pipe. The new
>> instance read mdev.conf, build a table of rules in memory, then read
>> hotplug operations from the pipe (send by the first instance). When
>> there are no more events for more then a few seconds, the first instance
>> closes the pipe and the second instance exits (freeing the used memory).
>> On next hotplug event a new pipe / second instance is created.
>
> I have a simlar idea, but slightly different. I'd like to separate the
> netlink listener and the event handler.

Ack. After thinking on Laurents message, I came to this, too. Split off 
the netlink part and use a pipe for communication. That can even go 
further, split off the initial sys scanning and hotlink parts from the 
parser and also use the pipe to communicate. Creating an mdev wrapper 
around this, so handling stays as is. This does not mean we need 
separate applets, may be can all include in one mdev applet with 
operation controlled by options. Later I will write a reply to Laurents 
message, going into more detail.

> I am thinking of using http://git.r-36.net/nldev/ which basically does the
> same thing as s6-devd: minimal daemon that listens on netlink and for
> each event it fork/exec mdev.

Ok, this may be a second alternative. As I do not want to reinvent the 
netlink part, I will take a deep look on the possible alternatives and 
try to adapt them for Busybox.

> - the mdev pipe fd is added to the poll(2) call so we catch POLLHUP to
>    detect mdev timeout. When that happens, set the mdev pipe fd to -1 so
>    we know that it needs to be respawned on next kernel event.

Why doing that so complicated? The mdev parser shall just read simple 
device add/remove commands from stdin until EOF, then exit. That's it. 
The netlink part can easily watch how long it is idle and then just 
close the pipe. As soon as more events arrive it creates a new pipe and 
fork another mdev parser. This needs time management and poll in only 
one program. All other code is simple and straight forward. The netlink 
reader, as a long lived daemon, already needs to watch the forked 
processes and act on failures.

... but those are details in implementation and some optimization. I 
agree on the ideas/functionality behind this.

> The benifits:
> - the netlink listener who needs to be running all times is very
>    minimal.

This may be an argument to have the netlink part not linked into BB, but 
does otherwise not change the idea behind this.

> - when there are many events within short time, (eg coldplugging), we
>    avoid the many forks and gain performance.

> - when there are no events, mdev will timeout and exit.

ACK

> - busybox mdev does not need set up netlink socket. (less intrusive
>    changes in busybox)

Can be done as an alternative so admin may decide if he likes to use 
netlink or hotplug helper. That is, nobody is forced to handle things in 
a special way. BB shall just give the tools to build easy setups.
Unwanted parts/applets may be left out on BB configuration (if size 
matters else default all tools in and let the admin chose).

> Then I'd like to do something similar with modprobe:
>   - add support to read modalias from stdin and have 1 sec timeout.
>   - have nldev to pipe/fork/exec modprobe --stdin on MODALIAS events.

Nice idea. May be with some slight modification for optimization of the 
timeout handling.

> That way we can also avoid the many modprobe forks during coldplug.

ACK, so the project needs a wider view. Thanks for pointing me to this.

... later more details in my Reply to Laurents message.

--
Harald