Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Mon, 8 Jan 2018 18:56:04 +0100

Hey there :)

So I've been using this (instead of your old uevent handler & busybox's
mdev) for a little while now, works great; Thanks!

I do have a few questions though. Originally what I had done was to
start mdevd, run mdevd-coldplug (referred to as coldplug thereafter),
and then start mdevd-netlink (referred to as netlinkd thereafter).

However, somewhat recently I believe I heard (read) you say on IRC that
the recommended way was actually the other way around, so I switched to
start netlinkd first, and then run coldplug.

But, it seems to me that when you're talking about this you expect one
to have two different instances of mdevd, one for netlinkd & another one
for coldplug. That's not how I made things however: mdevd is a longrun
and I simply have both coldplug & netlinkd piped into it.

So for that to work with this new setup/order, I needed to have both do
atomic writes, to ensure things don't get mangled/mixed up. (Wasn't
needed before as I could simply make sure netlinkd only starts after
coldplug, the later being a oneshot.)

Things were good for netlinkd, but not coldplug. So I simply patched it
to flush its output after each uevent. (This being linux and pipe,
I believe atomic writes are ensured so long as we don't go over 4KB,
which I assume won't happen for a single uevent.)

But since that means coldplug now performs a few more write calls, I'm
guessing you might not be interrested in doing such a change upstream,
or am I mistaking?
If not, does that mean the recommended way is really to have two
instances of mdevd? Or is there another/better way I'm not seeing? I
like to have only a single mdevd, one longrun (logged) service, as (I
feel) it should be.


On another topic of sorts: so I start mdevd, netlinkd, and run coldplug.
Cool. But what else would I need to do (upon boot) to ensure everything
has been processed correctly?

By that I mean, currently if I don't do anything else, some things
aren't processed. For instance, my audio card isn't there, neither are
a few input devices, such as my (usb) mouse.

So what I'm doing currently, is have a small trigger-uevents oneshot,
that does this:


#!/usr/bin/execlineb -P
pipeline { find /sys -type f -name uevent -print0 }
forstdin -0 -p f importas -u f f redirfd -w 1 $f echo add


It works, but I'm wondering whether this is the right thing to do, or if
there's a better/more correct way to get there?


Lastly, as a side note, on the doc for netlinkd, regarding the buffer
size, you say "The default is 65536 (which is on the large side)." (Same
as you did before for s6-uevent-listener I believe.)

Now I may be doing something wrong somewhere, but I've always had to use
a larger buffer to make sure things worked correctly myself (That is,
even before w/ s6-uevent-listener).
I'm currently using 1 MB (1048576) to be sure, though it should work
with a smaller one, but I know that even with 131072 (so twice your
"large side" default) I'd always get the following error during boot:

mdevd-netlink: fatal: unable to receive netlink message: No buffer
space available



Thanks!
Received on Mon Jan 08 2018 - 17:56:04 UTC