Precedence: list
MIME-Version: 1.0
In-Reply-To: <20160115045451.GA10573@newbook>
References: <20150728052436.GC1923@newbook>
	<CAO6-m02gSo0CeP7F=gTpsMukiNj+CUTM+FkJG86k-kGU=ZjVFA@mail.gmail.com>
	<20160112153804.GI32545@example.net>
	<56953ABE.5090203@skarnet.org>
	<CAFsQEP2Cx23cGcCTZ8e1RK+LOPtbvi=H6xUwuPH=9WqFQYg51A@mail.gmail.com>
	<56958E22.90806@skarnet.org>
	<CAFsQEP3K3HeP8dTx_Mi=hJYFDg9o3WmoYPsFcEN76z1pupR4pw@mail.gmail.com>
	<56964414.1000605@skarnet.org>
	<CAFsQEP0_iCUyuJgXbpDXORMry_SjhbfknJhKKRgcgKDd3vkeOg@mail.gmail.com>
	<56978822.8020205@skarnet.org>
	<20160115045451.GA10573@newbook>
Date: Sat, 16 Jan 2016 13:25:03 -0500
Message-ID: <CAFsQEP2yoLZ_-c0NBUKs-qmyKLuKtBBsPoGbChyE9mu8T4jOaQ@mail.gmail.com>
Subject: Re: [alpine-devel] udev replacement on Alpine Linux
From: Jude Nelson <judecn@gmail.com>
To: Isaac Dunham <ibid.ag@gmail.com>
Cc: Laurent Bercot <ska-devel@skarnet.org>, alpine-devel@lists.alpinelinux.org
Content-Type: multipart/alternative; boundary=001a11c2c7be7805de052977a360

--001a11c2c7be7805de052977a360
Content-Type: text/plain; charset=UTF-8

Hi Isaac,

On Thu, Jan 14, 2016 at 11:54 PM, Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Thu, Jan 14, 2016 at 12:36:02PM +0100, Laurent Bercot wrote:
> > On 14/01/2016 06:55, Jude Nelson wrote:
> > >I think you're close.  The jist of it is that vdev needs to supply a
> > >lot more information than the kernel gives it.  In particular, its
> > >helper programs go on to query the properties and status of each
> > >device (this often requires root privileges, i.e. via privileged
> > >ioctl()s), and vdev gathers the information into a (much larger)
> > >event packet and stores it in a directory tree under /dev for
> > >subsequent query by less-privileged programs.
> >
> >  I see.
> >  I think this is exactly what could be made modular. I've heard
> > people say they were reluctant to using vdev because it's not KISS, and
> > I suspect the ioctl machinery and data gathering is a large part of
> > the complexity. If that part could be pluggable, i.e. if admins could
> > choose a "data gatherer" just complex enough for their needs, I believe
> > it could encourage adoption. In other words, I'm looking at a 3-part
> > program:
> >  - the netlink listener
> >  - the data gatherer
> >  - the event publisher
> >
> >  Of course, for libudev to work, you would need the full data gatherer;
> > but if people aren't using libudev programs, they can use a simpler one,
> > closer to what mdev is doing.
> >  It's all from a very high point-of-view, and I don't know the details of
> > the code so I have no idea whether it's envisionable for vdev, but that's
> > what I'm thinking off the top of my head.
>
> I haven't really looked at the vdevd code in a while, but from what
> I recollect...
> The vdev/libudev-compat "solution" is split up as follows:
> -the netlink listener, vdevd
> -several data gatherers, which are invoked according to a set of rules
> for vdevd (analogous to mdev.conf)
> -helper scripts to create extra links and so on, run via the same rules
> -I don't recall exactly how the event publishing is done, but IIRC,
> there's a daemon watching the directory where the helpers write out the
> data, and then distributing it as described

-libudev-compat is libudev, patched to read events that are published
> as described
> -IIRC, there's some helper that will (also? instead?) maintain a list of
> devices more like the way udev does, so you don't *need* libudev-compat.
>

Yup--all the requisite device state is maintained under /dev/metadata.  The
libudev-compat event helper behaves just like any other vdev/mdev-style
script--when invoked, it reads /dev/metadata for a given device, sets up
the appropriate files in /run/udev, and generates, writes, and hard-links
the event-file (which libudev-compat clients detect and consume).
Libudev-compat is totally unnecessary if device-aware programs and scripts
can get away with reading and watching the contents of /dev/metadata.

-Jude

--001a11c2c7be7805de052977a360
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Isaac,<div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Thu, Jan 14, 2016 at 11:54 PM, Isaac Dunham <span dir=3D"ltr">&=
lt;<a href=3D"mailto:ibid.ag@gmail.com" target=3D"_blank">ibid.ag@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEn=
Zb"><div class=3D"h5">On Thu, Jan 14, 2016 at 12:36:02PM +0100, Laurent Ber=
cot wrote:<br>
&gt; On 14/01/2016 06:55, Jude Nelson wrote:<br>
&gt; &gt;I think you&#39;re close.=C2=A0 The jist of it is that vdev needs =
to supply a<br>
&gt; &gt;lot more information than the kernel gives it.=C2=A0 In particular=
, its<br>
&gt; &gt;helper programs go on to query the properties and status of each<b=
r>
&gt; &gt;device (this often requires root privileges, i.e. via privileged<b=
r>
&gt; &gt;ioctl()s), and vdev gathers the information into a (much larger)<b=
r>
&gt; &gt;event packet and stores it in a directory tree under /dev for<br>
&gt; &gt;subsequent query by less-privileged programs.<br>
&gt;<br>
&gt;=C2=A0 I see.<br>
&gt;=C2=A0 I think this is exactly what could be made modular. I&#39;ve hea=
rd<br>
&gt; people say they were reluctant to using vdev because it&#39;s not KISS=
, and<br>
&gt; I suspect the ioctl machinery and data gathering is a large part of<br=
>
&gt; the complexity. If that part could be pluggable, i.e. if admins could<=
br>
&gt; choose a &quot;data gatherer&quot; just complex enough for their needs=
, I believe<br>
&gt; it could encourage adoption. In other words, I&#39;m looking at a 3-pa=
rt<br>
&gt; program:<br>
&gt;=C2=A0 - the netlink listener<br>
&gt;=C2=A0 - the data gatherer<br>
&gt;=C2=A0 - the event publisher<br>
&gt;<br>
&gt;=C2=A0 Of course, for libudev to work, you would need the full data gat=
herer;<br>
&gt; but if people aren&#39;t using libudev programs, they can use a simple=
r one,<br>
&gt; closer to what mdev is doing.<br>
&gt;=C2=A0 It&#39;s all from a very high point-of-view, and I don&#39;t kno=
w the details of<br>
&gt; the code so I have no idea whether it&#39;s envisionable for vdev, but=
 that&#39;s<br>
&gt; what I&#39;m thinking off the top of my head.<br>
<br>
</div></div>I haven&#39;t really looked at the vdevd code in a while, but f=
rom what<br>
I recollect...<br>
The vdev/libudev-compat &quot;solution&quot; is split up as follows:<br>
-the netlink listener, vdevd<br>
-several data gatherers, which are invoked according to a set of rules<br>
for vdevd (analogous to mdev.conf)<br>
-helper scripts to create extra links and so on, run via the same rules<br>
-I don&#39;t recall exactly how the event publishing is done, but IIRC,<br>
there&#39;s a daemon watching the directory where the helpers write out the=
<br>
data, and then distributing it as described</blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
-libudev-compat is libudev, patched to read events that are published<br>
as described<br>
-IIRC, there&#39;s some helper that will (also? instead?) maintain a list o=
f<br>
devices more like the way udev does, so you don&#39;t *need* libudev-compat=
.=C2=A0<br></blockquote><div><br></div><div>Yup--all the requisite device s=
tate is maintained under /dev/metadata.=C2=A0 The libudev-compat event help=
er behaves just like any other vdev/mdev-style script--when invoked, it rea=
ds /dev/metadata for a given device, sets up the appropriate files in /run/=
udev, and generates, writes, and hard-links the event-file (which libudev-c=
ompat clients detect and consume).=C2=A0 Libudev-compat is totally unnecess=
ary if device-aware programs and scripts can get away with reading and watc=
hing the contents of /dev/metadata.<br><br>-Jude</div><div><br></div></div>=
</div></div>

--001a11c2c7be7805de052977a360--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---