Precedence: list
MIME-Version: 1.0
In-Reply-To: <20150727120744.4ffdfa0b@ncopa-desktop.alpinelinux.org>
References: <20150726103211.3A0FF1025EE9D@r-36.net>
	<20150727120744.4ffdfa0b@ncopa-desktop.alpinelinux.org>
Date: Thu, 30 Jul 2015 11:03:31 -0400
Message-ID: <CAFsQEP0pvphGo6uNjPCF0fn3RZKNduMThfVgr9bCOVn-RNLtkA@mail.gmail.com>
Subject: Re: [alpine-devel] udev replacement in Alpine Linux
From: Jude Nelson <judecn@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: alpine-devel@lists.alpinelinux.org
Content-Type: multipart/alternative; boundary=001a113f8ef2ae9177051c1901e5

--001a113f8ef2ae9177051c1901e5
Content-Type: text/plain; charset=UTF-8

Hi Natanael,

On Mon, Jul 27, 2015 at 6:07 AM, Natanael Copa <ncopa@alpinelinux.org>
wrote:

> On Sun, 26 Jul 2015 12:10:26 +0200
> Christoph Lohmann <20h@r-36.net> 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.

Thanks,
Jude

--001a113f8ef2ae9177051c1901e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Natanael,<div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Mon, Jul 27, 2015 at 6:07 AM, Natanael Copa <span dir=3D"ltr=
">&lt;<a href=3D"mailto:ncopa@alpinelinux.org" target=3D"_blank">ncopa@alpi=
nelinux.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun,=
 26 Jul 2015 12:10:26 +0200<br>
Christoph Lohmann &lt;<a href=3D"mailto:20h@r-36.net">20h@r-36.net</a>&gt; =
wrote:<br><br>
However, using netlink has the drawback that it requires a forever<br>
running daemon, and normally you only need it during bootup, and after<br>
that, you need it seldomly, when you plug in an usb disk, a mouse or<br>
similar.<br></blockquote><div><br></div><div>You may be interested to know =
that vdevd offers a command-line switch to have it synchronously &quot;patc=
h&quot; /dev and exit.=C2=A0 It finds the set of devices that the kernel kn=
ows about but are not represented in /dev and creates device nodes and meta=
data for them, and it removes the set of device nodes and metadata from /de=
v that are no longer recognized by the kernel.=C2=A0 The motivating use-cas=
e is to help server admins maintain a /dev that represents the set of avail=
able hardware without having to run a hotplug daemon in the background.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I am interested in libudev comaptibility, but have not looked too much<br>
into it. I don&#39;t need full ABI compatibility, but it would be very<br>
helpful to make it easy to port current applictions who uses libudev.<br></=
blockquote><div><br></div><div>In my experience creating vdev, I have found=
 that the key challenge in preserving libudev compatibility happy isn&#39;t=
 API or ABI compatibility, but is in generating the data they expect to pul=
l from /run/udev and device events.=C2=A0 This is because the metadata in /=
run/udev and the device packets sent by udev contain considerably more info=
rmation than is found in the kernel&#39;s uevent (for example, data returne=
d by privileged ioctls on devices, data queried from the hardware database,=
 etc.).=C2=A0 This information needs to be gathered and propagated to achie=
ve full compatibility--either by the device manager or by some other agent.=
=C2=A0 Unfortunately, the dependence on privileged ioctls precludes most li=
budev clients from loading the requisite information themselves; a sufficie=
ntly privileged program needs to load it and make it available on their beh=
alf.=C2=A0 Currently, that role is filled by udevd (and vdevd), but I could=
 imagine an alternative design where libudev-compat proactively gathered an=
d cached such information by periodically running a setuid helper built for=
 the purpose.</div><div><br></div><div>Thanks,</div><div>Jude</div><div><br=
></div></div><br></div></div>

--001a113f8ef2ae9177051c1901e5--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---