Le 13/11/2017 à 13:56, jacksprat a écrit :
hello Didier Kryn: thanks for bringing this to my [and everyones]
attention. My use of mdev "just seems to work", perhaps because I
just use my computers for boring "desktop duties".
I remember Devuan being very agressive when I tried to uninstall udev*
[dragging many other important packages with it].
I like the idea of only using the built-in Busybox commands to init
Linux [exceptions sdhcp and iptables]. I will explore mdevd properly
when it gets closer to 1.0.0.0!
thanks, jacksprat
Actually I sent the information to Jacksprat only, because it's
rather technical and he seems the guy most concerned. Now I have to give
it to the list (-:
A few weeks ago Laurent Bercot announced mdevd, a replacement for
Busybox's mdev which solves some unpleasant details of mdev.
Busybox's mdev is spawned by the kernel for every uevent, which can
cause a "fork bomb" at start up (a concern for very small and slow
systems); it parses its config file everytime, of course, and it needs a
trick with a lock file to serialize the processing of the uevents.
Instead, mdevd (Laurent's server) parses its config file (strictly
identical to mdev's) only once and reads uevents from its standard
input. It can be piped from a netlink reader (also provided), which is
the way to process uevents on the fly, or from another application (also
provided) which generates uevents from sysfs to update /dev with the
uevents generated by the kernel before mdevd was started. Since mdevd
gets its uevents from the netlink, they are naturally serialized.
The (little) drawback of mdevd is that it is constantly present in
the system, together with its netlink reader. Busybox's mdev, instead is
only present shortly when there is an uevent.
Here is the announcement:
-------- Message transféré --------
Sujet : [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
Date : Mon, 23 Oct 2017 08:02:33 +0000
De : Laurent Bercot <[email protected]>
Répondre à : Laurent Bercot <[email protected]>
Pour : [email protected] <[email protected]>,
[email protected] <[email protected]>
Hello,
About two years ago, there was some talk on the Busybox mailing-list
about the need for a version of "mdev" that would not use a separate
process for every uevent (as a hotplug manager does) but that would act
as a daemon, able to handle a series of uevents - typically read from
the netlink.
One of the goals of such a program was to reduce boot time on slow /
resource-constrained devices that don't like creating hundreds of
processes at the same time - especially when they contend for a
sequence number.
I took a quick look at the time, but came to the conclusion that the
way mdev was coded made it very difficult. Basically, mdev gets its
uevent variables from the environment, then reads and processes its
config file, performing actions as it goes. A quick hack to add
"daemon mode" support to mdev would still make it process the config
file for every event, similarly to what "mdev -s" does; this would
remove the forks but still be pretty inefficient, not to mention
particularly ugly. To implement "daemon mode mdev" in a clean way, a
full rewrite was needed. So I shelved the idea at the time.
Until now.
mdevd is an uevent manager reading a sequence of uevents and handling
them without forking, that understands the full /etc/mdev.conf format.
"mdevd-coldplug | mdevd" is equivalent to "mdev -s".
"mdevd-netlink | mdevd" is a daemon that listens to the netlink and
processes uevents sequentially, without the need for mdev.seq hacks
coming from the kernel spawning hotplug managers in parallel.
You can find it here:
https://skarnet.org/software/mdevd/
git://git.skarnet.org/mdevd
https://github.com/skarnet/mdevd
Since it's a full rewrite with a very different architecture from mdev
and little code reusability with the rest of Busybox, it did not make
sense to include it in Busybox, which is why it's provided as a
separate package.
Bug-reports welcome.
mdevd is still considered beta for some functionality I could not
extensively test, such as firmware loading. If your setup uses firmware
loading or otherwise obscure mdev features, I'm especially interested
in your reports and/or comments. (mdevd comes with a dry run mode, so
you don't have to be a reckless cowboy to test it.)
Enjoy,
--
Laurent
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
