[RFC] mdev: support reading events from stdin, add features to mdev -s

[Denys Vlasenko]

On Thu, Apr 16, 2015 at 5:16 AM, Isaac Dunham <ibid.ag at gmail.com> wrote:
> On Wed, Apr 15, 2015 at 06:46:08PM +0200, Denys Vlasenko wrote:
>> On Mon, Apr 13, 2015 at 7:15 PM, Isaac Dunham <ibid.ag at gmail.com> wrote:
>> > Here's a patch series to add mdev -i and make mdev -s a little more
>> > featureful, so rules like this one:
>> > $MODALIAS=.*    root:root 660 @modprobe "$MODALIAS"
>> > will work even with coldplug.
>> >
>> > mdev -i reads hotplug events from stdin, in a format proposed by Laurent Bercot
>> > wherein each "line" is terminated with '\0' (rather than '\n') and each event
>> > is terminated by an additional '\0'.
>> > Internally, each event is loaded into the environment (without copying) at
>> > the start of handle_event(), then the environment is cleared before
>> > handle_event() returns.
>> > This is done instead of using a new key lookup method because helper
>> > scripts rely extensively on environment variables; if we did not load
>> > the events into the environment at some point, autoloading modules and
>> > other important features would no longer work.
>> >
>> > The new mdev -s (FEATURE_MDEV_NEWSCAN) uses the same codepath as mdev -i
>> > instead of calling make_device() directly.
>> >
>> > Both mdev -i and the new mdev -s are compile-time options, separately
>> > selectable.
>>
>> How about the following applet, which would listen to netlink and spawn a helper
>> for every new message?
>>
>> So far not tested with "mdev".
>
> Your proposed applet is essentially interchangeable with nldev and s6-devd.
> Yes, it's a nice concept.
>
> But it doesn't address the number of forks that happen if you use mdev as
> a hotplugger during system startup, which can overwhelm some systems
> (depending on the hardware and the kernel configuration) or cause
> relatively slow boots when you provide an mdev.conf for all possible
> hardware (as is required for a distro package), since every instance of
> the hotplugger has to reparse the config file.
>
> To solve these problems, Harald Becker, Laurent, and Natanael Copa had
> proposed to allow mdev to serve as a longer-running process that would
> read a textual dump of events from stdin ("mdev -p"/ "mdev -i").
>
> Harald had a much larger set of changes in mind, including turning the
> hotplug helper into something that forwards events to the reader and
> making mdev mount the needed filesystems, which was the cause of the big
> argument about mdev.
> (That was the thread "RFD: Rework/extending functionality of mdev").
>
> Laurent Bercot and Natanael thought that letting mdev read from a pipe
> sounded good, and was the only part of the extra functionality that was
> needed. There was some disagreement about whether to let mdev timeout
> and exit when no hotplug events happen in a specified duration.
> A bit of discussion related to this is in the thread
> "[RFC] Proof-of-concept for netlink listener for mdev -i".
> Eventually, Nataneal made nldev work like he wanted, then wrote a minimal
> patch to implement mdev -i (with timeout), requesting that someone else
> pick up where he left off (these are the first two patches).
> The third and fourth patches in the series are my try at finishing it,
> and I ended up implementing a version of mdev -s that's equivalent to
> hotplugging in features (because the refactoring made it easy).
>
> As a note for review, the second patch has a few issues with it that are
> addressed in the third patch; I was considering squashing them together,
> but left them separate to acknowledge Natanael Copa's part in writing it.

1.24.x has this applet under "uevent" name.
Sorry, it is a spawner...

# pmap `pidof uevent`
1279: uevent mdev
08048000     868K r-xp  /app/busybox-1.24.1/busybox
08121000       8K rw-p  /app/busybox-1.24.1/busybox
08123000       4K rw-p  [heap]
f77ca000      16K rw-p    [ anon ]
f77ce000       8K r--p  [vvar]
f77d0000       4K r-xp  [vdso]
ff945000     132K rw-p  [stack]
mapped: 1040K

The interesting trick here is that 16K buffer for reading
is entirely not mapped until kernel has something to say:

# cat /proc/`pidof uevent`/smaps | grep -e'^[0-9a-f]' -e^Size -e^Rss
08048000-08121000 r-xp 00000000 08:05 1145
  /app/busybox-1.24.1/busybox
Size:                868 kB
Rss:                 376 kB
08121000-08123000 rw-p 000d9000 08:05 1145
  /app/busybox-1.24.1/busybox
Size:                  8 kB
Rss:                   8 kB
08123000-08124000 rw-p 00000000 00:00 0                                  [heap]
Size:                  4 kB
Rss:                   4 kB
f77ca000-f77ce000 rw-p 00000000 00:00 0
Size:                 16 kB
Rss:                   0 kB <---------------- HERE
f77ce000-f77d0000 r--p 00000000 00:00 0                                  [vvar]
Size:                  8 kB
Rss:                   0 kB
f77d0000-f77d1000 r-xp 00000000 00:00 0                                  [vdso]
Size:                  4 kB
Rss:                   0 kB
ff945000-ff966000 rw-p 00000000 00:00 0                                  [stack]
Size:                136 kB
Rss:                   8 kB

All in all, only four dirty pages are in userspace:
two for .data and two for stack