RFD: Rework/extending functionality of mdev

Isaac Dunham ibid.ag at gmail.com
Wed Mar 11 17:16:45 UTC 2015


On Wed, Mar 11, 2015 at 02:30:13PM +0100, Harald Becker 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 :(

Agreed, whole-heartedly.
I just don't think you're quite thinking through exactly what this means.

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

Agreed.
But I would include "hotplug daemons" under "etc."

<snip>
> ... using this wider view, I tried to find a modular solution for the device
> system management (here mdev):
> 
> Maximum code sharing means to have a look on flow of data and try not to
> duplicate same functionality into different commands. For the device
> management I see the following different usage scenarios:
> 
> - not using hotplug feature, semiautomatic device node setup
>   (currently user calls "mdev -s" when required)
> 
> - using the hotplug handler approach of the kernel
>   (current operation of "mdev")
> 
> - using a netlink based hotplug approach
>   (currently not in Busybox, but external tools exit, e.g. nldev)
> 
> 
> The current implementation suffers on event bursts, due to massive forking a
> separate parser for each event. So one of the major design decisions has to
> be avoiding those unnecessary parallelism. It does not only suffer from
> resource consumption, the parallelism is contra productive for device event
> management, due to not serialized operation.
> 
> 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.

That *shall* is where you're forgetting about the first principle you
mentioned (assuming that you mean "shall" in the normative sense used
in RFCs).

Yes, some people find the hotplugger too slow.
But that doesn't mean that everyone wants a new architecture.

Some people, at some points in time, would prefer to use a plain, simple,
hotplugger, regardless of whether it's slow.
(Personally, I'd like a faster boot, but after that a hotplugger that
doesn't daemonize is fine by me.)
At present, those people are most likely using mdev.

So, in order to respect that preference, it would be nice if you could
let the hotplug part of mdev keep doing what it does.

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

I understand that the goal here is to allow people to use netlink or hotplug
interchangeably with "mdev -p" (which I still think is a poorly named
but very desireable feature).

As stated before, I don't think that this approach is really functional,
and would be more opposed to using it than to using netlink or a plain
hotplugger. For this reason, I'm opposed to including it in *mdev*.

I also think that those who *do* want to use this approach would benefit
more from a non-busybox binary, since the hotpluggger needs to be as
small and minimal as possible. Hence, I suggest doing it outside busybox.

But *if* you prefer to have it in busybox, I'd suggest doing a new applet
named (for example) "afifohp" (A FIFO HotPlugger, so named because it
would be one of the first entries in the multiplexer and that's what
it does).
This would become the FIFO-reading daemon if need be, and dump its
environment into the fifo or (as daemon) read from the fifo, spawn
mdev -p, and write to a pipe.
I'd assume it needs a *simple* config file, which could be just a line
or two:
/sbin/mdev -p
timeout <n>

> 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)
> 
> - 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). The parser process reads the
> conf file on startup, then start to read commands from the fifo (written by
> a gathering part).

I understand this architecture.
I'm saying that 
* Since I think that the hotplug-compatible shim is worse than a plain
hotplugger, I would much prefer it if you left us a plain hotplugger
* If you do want to use this architecture, keeping this shim as minimal
as possible is extremely desireable; this implies that it should not be in
mdev, and probably not in busybox.

> Adding initial setup of the device file system as a functional block to the
> device management, allows to arrange for having a one-shot device system
> startup. Consider emergency shell usage, with a minimalist system started in
> memory (e.g. starting kernel wit /bin/sh as init). Then you need to do some
> base setup get a usable system, with bringing up the device management of
> one central part of operation. Then you would most benefit from a one-shot
> startup. At startup which is *not* hard coded in it's operation, it is just

I've used init=/bin/sh many times.
If I forget the correct commands, I usually go
 cat /etc/init.d/<hotplug handler>
or something similar; this is sometimes but not always on the same computer.

But there are difficulties that adding "mdev -i" causes:
-If someone refers to a computer where it's configured to set up one where
it isn't, this can cause major confusion.
-Someone could use it in their initscripts, but end up getting an
incompatible mdev.conf (for example, if a packager switches it on
without guaranteeing that the new entries find their way into mdev.conf,
it will likely cause widespread failure to boot.)
-It means that I have to refer to two files, and decode mdev.conf
into shell.

Adding "mdev -h" is likely to cause more confusion, since "-h" is commonly
used to find help.
A line in the help text mentioning 
echo /sbin/mdev >/proc/sys/kernel/hotplug
would be at least as helpful.

Besides, I think that Denys has a good point about the Unix way.
 
> The following questions to this topic:
> 
> - are MODALIAS requests send to same netlink socket as device events?

I would assume so, since they're part of the uevents.
I haven't checked, though.

> - does the module handling need and / or benefit from synchronization with
> the device node handling, or is choosing parallelism the better approach?

Generally, you will either load a module or make a device node.
It's *possible* that you'll need to do both in some odd case.

Thanks,
Isaac Dunham


More information about the busybox mailing list