On 3/11/2015 9:30 AM, Harald Becker wrote:
So how can we avoid that unwanted parallelism, but still enable all of
the above usage scenarios *and* still have a maximum of code sharing
*and* a minimum of memory usage *without* delaying the average event
handling too much?
The gathering parts need to acquire the device information, sanitize
this information, and serialize the event operations to the right
order. The device node handling part shall receive the information
from the gathering part(s) (whichever is used) and call the required
operations, but shall avoid reparsing the conf on every event (speed
up) *and* drop as much memory usage as possible, when the event system
is idle.
My idea is a fifo approach. This allows splitting the device
management functionalities. Nevertheless which approach to gather the
device information is used, the parser and device handling part can be
shared (even on a mixed usage scenario).
Supposing that we have
* mdev acting as a parallel hotplug handler forked by the kernel
and then add
* mdevd which reads netlink messages and runs as a daemon
What specifically is the appeal of a third approach which tries to
re-create the kernel netlink design in user-land using a fifo written
from forked hotplug helpers?
I'm interested in this thread, but there is too much to read. Can you
explain your reason in one concise paragraph?
-Mike
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
