RFD: Rework/extending functionality of mdev

[Harald Becker]

Hi !

To Michael:

Don't be confused, Natanael provided an alternative version to achieve 
the initial device file system setup (which isn't bad, but may have it's 
cons for some people on small resource constrained systems of the 
embedded world). So I left it out for clarity ... but still may be 
implemented / used as an alternative method for setup.


To Natanael:

On 12.03.2015 10:14, Natanael Copa wrote:
>> - The third method (scanning sys file system) is the operation of "mdev
>> -s" (initial population of device file system, don't mix with "mdev" w/o
>> parameters), in addition some user take this as semi automatic device
>> management (embedded world)
>
> I disagree here. mdev -s solves a different problem.

No.

> there are 2 different problems.
>
> 1) handle hotplug events.
 >
>
>     There are only 2 methods for this problem:
>        A) using 1 fork per event (eg /sbin/mdev
>          in /proc/sys/kernel/hotplug). this is simple but slow.

This is "mdev" (without any parameters).


>        B) reading hotplug events via netlink using a long lived daemon.
>        (like udev does)

Currently not in mdev, but shall be an alternative mechanism in my 
implementation, so you may chose and use the mechanism you like.

> 2) do cold plugging. at boot you need configure the devices kernel
>     already know about.

This is the operation of "mdev -s"


>         B) solve problem 1 mentioned above (set up a hotplug handler)
>         and then trigger the hotplug events. Now you don't need scan the
>         sysfs at all.

But still there are people in the embedded world, who like (or are 
forced) to use semi automatic device handling, that is calling something 
like "mdev -s" to scan sys file system for new devices.

My approach is to give them all the possibility to device management 
withe mechanism they like, without maintaining different device 
management systems and duplicating the code.

Three different mechanisms, with three different front end's, and one 
shared back end.

... the only thing I see is a difference in initial device system 
population. You provided a different method to trigger the coldplug 
events (and yes, I understand that approach), but that one will only 
work when you either use the kernel hotplug helper mechanism, or the 
netlink approach. You drop out those who can't / doesn't want to use either.

I left that out in the "short" summary for Michael, but didn't forget 
your hint. May be we can have an additional alternative for the setup 
part, implementing event triggering (still we do the sys file system 
scan, but with different handling then) ... or you do it in scripting, 
setup your hotplug handler or netlink listener and then run a script to 
trigger the plug events (nice idea otherwise, I like it, but won't 
unnecessary drop people on the other end).

> What I currently do is:
> - for problem 1 (dealing with hotplug events) I use method A.
>
> - for problem 2 (set up devices at boot) I use method A because my
>    hotplug handler is slow due to many forks.
>
> What I would like to do is switch to method B for both problem 1 and
> method B for problem 2 too. However, I want the long lived daemon
> consume less memory and i want be able to use the mdev.conf syntax for
> configuring the devices.

No problem, my approach shall give the possibility to do it the way you 
like, without blocking the others. Still you need to do the following 
steps on system startup:

- initial creation of the device file system (out of scope of mdev)

- prepare your system for hotplug events, either kernel method or 
netlink  (if you go that way)

- trigger initial device file system population (cold plug)
   (may be done in two ways, yours or the old "mdev -s")


>> - So how can we have all three methods without duplication of code, plus
>> how can we speed up the kernel hotplug method?
>
> IMHO, there are not 3 methods so the rest of discussion is useless.

You are going to force others to do it the way you like and everything 
other is of no interest?

I'm trying to give most people the possibility to do it the way they 
like, your way inclusive! ... without blocking other methods (or may be 
external implementations with reusage of conf / handling back end).

... as other functions in BB, unwanted functionalities may be opted out 
in build config.

... so this would mean for you: Include the back end and the netlink 
into your Busybox, do the usual device file system creation, activate 
the netlink handler (shall auto start the fifo watcher), then trigger 
cold plug events (undiscussed if done with script or added to binary).

Anything wrong with this?

--
Harald