On Tue, Mar 10, 2015 at 05:26:20PM +0100, Harald Becker wrote:
> Hi,
>
> getting hints and ideas from Laurent and Natanael, I found we can get most
> flexibility, when when try to do some modularization of the steps done by
> mdev.
>
> At fist there are two different kinds of work to deal with:
>
> 1) The overall operation and usage of netlink
> 2) Extending the mdev.conf syntax
>
> Both are independent so first look at the overall operation ... and we are
> currently looking at operation/functionality. This neither means they are
> all separate programs/applets. We may put several functionalities in one
> applet and distinguish by some options. First look at, what to do, then
> decide how to implement:
>
> mdev needs to do the following steps:
>
> - on startup the sys file system is scanned for device entries
>
> - as a hotplug handler for each event a process is forked passing
> information in environment variables
>
> - when using netlink a long lived daemon read event messages from a network
> socket to assemble same information as the hotplug handler
>
> - when all information for an event has been gathered, mdev needs to search
> it's configuration table for the required entry, and then ...
>
> - ... do the required operations for the device entry
>
s/mdev/"a complete fully generic device manager"/
I think that only one of the proposed enhancements belongs in mdev;
the netlink daemon could be a useful new applet;
and maybe it would be useful to add mount -T <fstab> and an option
to create missing paths (-m?) so someone can add /etc/kernfstab like so:
# Kernel filesystems
devfs /dev devtmpfs rw,nosuid,noexec
proc /proc proc rw,nosuid,noexec,nodev
sysfs /sys sysfs rw,nosuid,noexec,nodev
#no idea if this will work right:
/proc/self/fd /dev/fd auto bind,mode=0700
devpts /dev/pts devpts rw,nosuid,noexec
devshm /dev/shm tmpfs defaults
And then in the init scripts:
# mount kernel filesystems
mount -T /etc/kernfstab -m -a
# make any links you need
# start the netlink daemon and mdev
nld -e "/sbin/mdev -i"
mdev -s
find /sys -name modalias -exec cat '{}' + | xargs modprobe -abq
> ... but ok, do we look at an alternative: Consider a small long lived
> daemon, which create a named fifo and then poll this fifo until data get
> available. On hotplug event a small helper is started, which read it's
> information, serializes then write the command to the fifo and exit. The
> long lived daemon sees the data (but does not read), then forks a parser and
> gives the read end of the pipe to the the parser. The parser reads mdev.conv
> once, then processes commands from the fifo. Now we are at the situation
> where the timeout needs to be checked in the parser. When there are no more
> events on the fifo the parser just dies successfully (freeing used memory).
> This will be detected by the small long lived daemon, which check the exit
> status and can act on failures (e.g. run a failure script). On successful
> exit of the parser the daemon starts again waiting for data on the fifo
> (which he still hold open for reading and writing). This way the hotplug
> helper will benefit from a single run parser on startup, but memory used by
> the conf parser is freed during normal system operation. The doubling of the
Yuck!
This looks like a hideous overdesign trying to duplicate the netlink
layer by writing a multi-part shim that pretends to be a hotplug helper
on one side and devd on the other.
If you don't want the problems of a hotplug helper, there's a simple
solution: don't use a hotplug helper.
This approach gives you almost all the disadvantages of both worlds,
plus its own:
* You need to manage a hotplugger daemon.
* Hotplug events must be manually serialized (by the fifo-reader), or you
may render the race conditions that a daemon is intended to avoid
inevitable
* Upgrades get more complicated
* You can still fork-bomb the system by too many hotplug events
* While you don't pay for parsing multiple times, the hotplug helper
can't be part of Busybox or it pays very steeply.
IF someone did want to do this (for example, if they have a custom
no-netlink kernel for an *extremely* small system), it would seem that
the most sensible course would be to write a custom hotplugger and
daemon, stripped down to the ~100 lines of C that it should take,
and use klibc or libc.h to make a static binary that's as small as
possible.
If the kernel has to start Busybox for every hotplug event, there
will be some overhead.
But whatever you do, *don't* make the rest of us adopt a newer, more
complicated, structure. More moving parts means more breakage,
and you *don't* take working, tested, paths and replace them with
some new code that Should Just Work(TM).
And I don't think that those who prefer mdev necessarily will be pleased
with this design.
> With mdev as a wrapper we could have:
>
> mdev (no parameter)
> - hotplug helper
> (how to get FIFO_PATH? use always default?)
>
> mdev -i
> - do the initial operations from mdev.conf
> (e.g. mounts, subdirs, symlinks)
>
> mdev -f [FIFO_PATH]
> - start the fifo helper daemon and create the fifo
> (suggesting default FIFO_PATH /dev/ctl/mdev)
>
> mdev -h [FIFO_PATH]
> - install mdev as a hotplug helper
> (needs to give FIFO_PATH to the hotplug helper, how?)
>
> mdev -n [FIFO_PATH]
> - start the netlink reader daemon
>
> mdev -s [FIFO_PATH]
> - scan the sys file system and populate device filesystem
>
> mdev -p
> - mdev.conf parser, reading from stdin (no fifo, no helper daemons)
> This way you may implement your own hotplug handling but continue to use the
> mdev.conf functionality.
>
> The options i f h and s may be combined, same for i f n and s, for which
> will allow to startup the system with a single call, doing init, loading
> required daemon(s), and scan sys file system for initial population. h n and
> s include f, when fifo does not exist.
>
Counter-proposal for each of your options:
mdev (no parameter)
- don't modify from existing
Proposed functionality should be outside busybox, if it's used.
mdev -i
- use mount -T (and makedevs if desired) instead
mdev -f FIFO
- don't have this in busybox; if using this approach, use a standalone
minimal static daemon
mdev -h
- use sysctl or echo. No, you don't need to replace
echo /sbin/mdev >/proc/sys/kernel/hotplug
with a new option; that's GNU thinking.
mdev -n
- use new applet, such as "nld"
This applet should have a -t option to set the timeout.
mdev -s
- as in present, but possibly setting an env variable for each line
that seems to match a $FOO= rule -- if there's a rule like
$MODALIAS=<value> root:root 660 @modprobe $MODALIAS
any line beginnning with MODALIAS= will get loaded into the environment,
checked for a match, run if need be, then unset and freed.
mdev -p
- same functionality, but another name would be *much* better.
I suggested mdev -i for this, and would prefer that on the grounds
that only programmers care about the fact that it's pre-parsing
the config file; as a *user*, I'd find
"-i read events from stdin"
to be much more obvious.
Thanks,
Isaac Dunham
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
