RFD: Rework/extending functionality of mdev

[Natanael Copa]

On Wed, 11 Mar 2015 14:30:13 +0100
Harald Becker <ralda at gmx.de> wrote:

> Hi Natanael !
> Hi Isaac !
> 
> Looks like you misunderstand my approach for the mdev changes ... ok, 
> may be I explained it the wrong way, so lets go one step back and start 
> with a wider view:
> 
> IMO Busybox is a set of tools, which allow to setup a working system 
> environment. How this setup is done, is up to the distro / system 
> maintainer, that is it is up their preferences.
> 
> I really like the idea to have an optimized version using netlink for 
> the hotplug events and avoid unnecessary forking on each event, but 
> there are other people which dislike that approach and prefer to use the 
> hotplug handler method, or even ignore the hotplug feature completely 
> and setup device nodes only when required (semi automatic, not manual 
> mknod, but manual invoking of mdev).
> 
> The world is not uniform, where all people share the same preferences, 
> so we need to be polite to accept those different kinds of preferences 
> and don't try to force someone to setup their system in a specific way.
> 
> Right? ... else we would be at the end of discussion and the end of my 
> project approach :(
> 
> ... but I think you will agree:
> 
> As Busybox is the used tool set, it shall provide the tools for all 
> users, and shall not try to force those users to use netlink, etc.

So netlink listener should not be implemented in mdev.

I agree on that.
 
...
 
> My idea is a fifo approach.

FIFO = first-in-first-out

I assume that you are talking about named pipes (aka fifos)
http://en.wikipedia.org/wiki/Named_pipe

> 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).

 
> So we have the following functional blocks for our device management:
> 
> - initial setup of the device file system environment
>    (yes, can be done by shell scripting, but it is a functional block)
> 
> - starting the fifo management and automatic parser invocation
>    (long lived minimalistic daemon)
> 
> - manual scanning of the sys file system and gathering device info
> 
> - setting up the usage of the hotplug helper system
>    (check fifo availability and set hotplug helper in kernel)
> 
> - an hotplug helper spawned by the kernel on every event
>    (should be as small / fast as possible)
> 
> - a netlink based event receiptor
>    (long lived daemon, small memory foot print)

Why do you need a hotplug helper spawned by kernel when you have a
netlink listener? The entire idea with netlink listener is to avoid the
kernel spawned hotplug helper.

It simply does not make sense to have both.

> - the device node handling part
>    (conf table parser / calling required operation)
>
> Where the gathering parts may be used according to the user
> preferences (and may be opted out on BB configuration).
> 
> Every gathering part grabs the required information, sanitizes, 
> serializes and then write some kind of command to the fifo. The fifo 
> management (a minimalist daemon) starts a new parser process when
> there is none running and watches it's operation (failure handling).

If you are talking about named pipes (created by mkfifo) then your
"fifo approach" approach will break here.

Once the writing part of the fifo (eg a "gathering part") is done
writing and closes the writing part, the fifo is consumed and needs to
be re-created. no other "gathering part" will be able to write anything
to the fifo.

Basically what you describe as a "fifo manager" sounds more like a bus
like dbus.

I think you are on wrong way. Sorry.

-nc