On Thu, 12 Mar 2015 20:00:55 +0100 Harald Becker <ra...@gmx.de> wrote:
> 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) This what I had in mind and tried to demonstrate with the hacked nldev.c and nldev-handler.c > ... 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 What happens if new event comes after netlink manager is started up but before the netlink listener is setup up? For example /dev/sda event comes and the user space hotplug program is fork/executed, but before it has reached to set up netlink listener the event for /dev/sda1 comes. How do you prevent races? I suppose you would need kernel help for solving that properly, like Denys suggested. -nc _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
