Mail archive

Re: [alpine-devel] udev replacement in Alpine Linux

From: Jude Nelson <>
Date: Thu, 30 Jul 2015 11:03:31 -0400

Hi Natanael,

On Mon, Jul 27, 2015 at 6:07 AM, Natanael Copa <>

> On Sun, 26 Jul 2015 12:10:26 +0200
> Christoph Lohmann <> wrote:
> However, using netlink has the drawback that it requires a forever
> running daemon, and normally you only need it during bootup, and after
> that, you need it seldomly, when you plug in an usb disk, a mouse or
> similar.

You may be interested to know that vdevd offers a command-line switch to
have it synchronously "patch" /dev and exit. It finds the set of devices
that the kernel knows about but are not represented in /dev and creates
device nodes and metadata for them, and it removes the set of device nodes
and metadata from /dev that are no longer recognized by the kernel. The
motivating use-case is to help server admins maintain a /dev that
represents the set of available hardware without having to run a hotplug
daemon in the background.

> I am interested in libudev comaptibility, but have not looked too much
> into it. I don't need full ABI compatibility, but it would be very
> helpful to make it easy to port current applictions who uses libudev.

In my experience creating vdev, I have found that the key challenge in
preserving libudev compatibility happy isn't API or ABI compatibility, but
is in generating the data they expect to pull from /run/udev and device
events. This is because the metadata in /run/udev and the device packets
sent by udev contain considerably more information than is found in the
kernel's uevent (for example, data returned by privileged ioctls on
devices, data queried from the hardware database, etc.). This information
needs to be gathered and propagated to achieve full compatibility--either
by the device manager or by some other agent. Unfortunately, the
dependence on privileged ioctls precludes most libudev clients from loading
the requisite information themselves; a sufficiently privileged program
needs to load it and make it available on their behalf. Currently, that
role is filled by udevd (and vdevd), but I could imagine an alternative
design where libudev-compat proactively gathered and cached such
information by periodically running a setuid helper built for the purpose.


Received on Thu Jul 30 2015 - 11:03:31 UTC