RFD: Rework/extending functionality of mdev

[Michael Conrad]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20150311/89c33285/attachment.html>