Hi Natanael !
My point is that a long lived daemon that stays there 5 hours after
the last hotplug event is currently unavoidable unless you are ok
with one fork/exec for every event.
Why not logical splitting the function?
- one listener which is gathering data, and forward sanitized messages
- one consumer / handler job, started when required but dies when idle
(meanwhile that single job consumes the messages and act on them)
... and compare that to operation of e.g. tcpsvd ... setup network
socket, accept incoming connections, fire up handling server program ...
so what is the difference?
Crazy idea:
have a netlink listener/handler that is installed in
/proc/sys/kernel/hotplug.
On startup it will set up a netlink listener and remove itself from
/proc/sys/kernel/hotplug so all subsequent events comes via netlink.
Read events from netlink and handle those.
On timeout (no events for N seconds), restore itself in
/proc/sys/kernel/hotplug and exit.
I don't think this is possible to implement without race conditions
so I still believe a minimal forever running netlink listening
daemon is the way to go.
Crazy! ... but otherwise ACK ... you may try this, on my intended
modular device management. Modify the hotplug helper to disable hotplug,
fire up netlink, but don't loose the initial hotplug handler event ...
but I don't expect main stream stability
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
