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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
