Message-ID: <55B67C49.9040007@landley.net>
Date: Mon, 27 Jul 2015 13:45:29 -0500
From: Rob Landley <rob@landley.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
Precedence: list
MIME-Version: 1.0
To: Natanael Copa <ncopa@alpinelinux.org>
CC: Alan Pillay <alanppillay4@gmail.com>, 
 alpine-devel@lists.alpinelinux.org, judecn@gmail.com, sin@2f30.org, 
 hiltjo@codemadness.org, frank@tuxrocks.com, dev@frign.de
Subject: Re: [alpine-devel] Re: udev replacement on Alpine Linux
References: <CAO6-m02qfTUZeW9a0+WZY9eqEgnr50T27m4vPy5Y6unc64kNeA@mail.gmail.com>	<55B4554A.6020708@landley.net> <20150727120052.315fa82b@ncopa-desktop.alpinelinux.org>
In-Reply-To: <20150727120052.315fa82b@ncopa-desktop.alpinelinux.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 07/27/2015 05:00 AM, Natanael Copa wrote:
> On Sat, 25 Jul 2015 22:34:34 -0500
> Rob Landley <rob@landley.net> wrote:
> 
>> On 07/25/2015 07:11 PM, Alan Pillay wrote:
>>> Dear Alpine Linux developers and mailing-list lurkers,
>>>
>>> udev is currently being used on Alpine version 3.2.2, but we all know
>>> it detracts from the philosophy to keep things simple, small and
>>> efficient.
>>> There are many programs out there that could replace udev and help
>>> Alpine get in a better shape. I will list some that I know.
>>>
>>> [mdev] there are 2 mdev implementations that I know, busybox's and
>>> toybox's. On Alpine Linux, busybox already comes installed by default
>>> (and its mdev comes with it, which is weird since it isn't currently
>>> used, but I digress)
>>
>> I'm the primary developer of toybox and the original author of busybox
>> mdev, but busybox's mdev has grown a lot of new features over the years
>> that toybox doesn't implement yet.
> 
> Busybox mdev has lots of feature/solutions for problems that I think
> should not been there in first place. For example firmware loading, now
> handled by kernel, device node creation could be handled by devtmpfs
> (if we want be able to optionally use udev for Xorg we will need
> devtmpfs anyway).

I lean towards devtmpfs too, but you just listed requiring it as one of
the _downsides_ of eudev if I recall... :)

At some point I need to immerse myself in this for a month to design and
implement The Right Thing. Unfortunately, it's about 12th on the list,
especially since Android does its own thing we're unlikely to displace,
and that's literally a billion seats. (Getting android, posix, lsb, and
the prerequisites of a linux from scratch build right are the top
priorities, everything else comes after that unless people submit
patches and to be honest usually a couple follow up pokes.)

> busybox mdev has also a solution for serialization of the
> hotplug events, which I think is an ugly hack. Code could have been
> simpler by just reading events from netlink.

I have a patch to do that somewhere, actually. Not against it, just...
that requires a persistent demon, which the historical mode doesn't.

>> I'm happy to add them, but am mostly waiting for patches from the users
>> telling me what they need. (My own embedded systems mostly just use
>> devtmpfs, they don't tend to hotplug a lot of stuff.)
> 
> So what I have been thinking:
> 
> a netlink socket activator[1], which when there comes an event, fork
> and execs a handler and passes over the the netlink socket.

Wasn't requiring a new fork for each event was a performance bottleneck
in what the sash guys wrote, last email?

> The handler reads various events from netlink socket. It should be able
> load kernel modules without forking, and ideally, it should be able to
> handle each event without forking, including doing blkid lookups
> without forking.

Note: last time I benched this fork was 5% of the overhead and exec was
95% of the overhead. Is fork what you object to, or is process spawning
what you  object to?

Toybox can fork() and internally run insmod or modprobe as a builtin
command without re-execing itself (except on nommu). The reason for the
fork() is to avoid needing to clean up after commands, especially from
error paths that exit halfway through because it couldn't open a file or
something. (There's a recursion limit, after 9 recursive invocations it
invokes the exec() path anyway to keep the stack size down to a dull
roar. But that doesn't come up much in practice.)

I _can_ do nofork calls to various commands, but daemons are careful to
avoid xfunction() library calls that exit on error, and most other
commands aren't, and even if I audit what's there now relying on it to
stay that way is a regression waiting to happen. (Maybe at some point
I'll expand the nofork stuff, but it's a can of worms and I'm going for
simplicity where possible.)

> After one or two seconds without any netlink event it
> will exit and the socket activator takes over again.

By socket activator you basically mean an inetd variant?

> There was a huge thread about netlink and mdev in busybox mailing list.

I catch up on that _maybe_ yearly these days, lemme see... Google says:

http://lists.busybox.net/pipermail/busybox/2015-March/082690.html

> There were some strong opinions of making a more general read events
> from any pipe, but I think that needlessly complicates things.
> 
> I am also interested in loading modules without forking, so I was
> thinking of making modprobe read modaliases from a stream. Doing so in
> busybox would require a major refactoring so I instead looked at using
> libkmod for that. But then libkmod only works with binary format of
> modaliases so busybox depmod needed a fix[2][3] to generate a binary
> format of the indexes so libkmod can read those.

The whole of toybox insmod is 46 lines. (There's a 568 line modprobe in
toys/pending but there's a _reason_ it's in pending.)

> The current plan is to use nlsockd as socket activator, a netlink
> reader[4] which will load kernel modules with libkmod and fork mdev -
> but only on the relevant events - those who has DEVNAME set.

No man page in ubuntu, and when I type the command it doesn't suggest a
packakge to install...

Ah, your email has a bibliography.

>> If there's interest in my fleshing out toybox's mdev, I can bump it up
>> the todo list, but I tend to be chronically overcommitted so need
>> repeated poking...
> 
> What I might be interested in is making toybox mdev read events from a
> netlink socket (stdin or other filedescriptor),

-n netlink file descriptor

> add support for loading modaliases without forking.

Again, fork, or exec?

(If you really care that much I could probably move the modalias parsing
stuff to lib, it's really #include <linux/blah.h> from lib I try to
avoid. Building on bsd you can switch off commands, but lib/*.c gets
compiled unconditionally and then --gc-sections trimmed.)

Rob


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---