Precedence: list
MIME-Version: 1.0
In-Reply-To: <CAO6-m02qfTUZeW9a0+WZY9eqEgnr50T27m4vPy5Y6unc64kNeA@mail.gmail.com>
References: <CAO6-m02qfTUZeW9a0+WZY9eqEgnr50T27m4vPy5Y6unc64kNeA@mail.gmail.com>
Date: Sat, 25 Jul 2015 20:51:12 -0400
Message-ID: <CAFsQEP1Z606oZ1ngcsccmtA_E1_F-Db-WkuOWcnk5XuB7dD4zQ@mail.gmail.com>
Subject: [alpine-devel] Re: udev replacement on Alpine Linux
From: Jude Nelson <judecn@gmail.com>
To: Alan Pillay <alanppillay4@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org, sin@2f30.org, hiltjo@codemadness.org, 
	rob@landley.net, frank@tuxrocks.com, dev@frign.de
Content-Type: multipart/alternative; boundary=001a113f90482b0793051bbca2f3

--001a113f90482b0793051bbca2f3
Content-Type: text/plain; charset=UTF-8

Hi everyone,


> [vdev] a device manager with an approach a bit different, offers an
> optional filesystem interface that implements a per-process view of
> /dev. Possibly the least simple alternative, but interesting
> nonetheless.
>
>
Thank you for your interest in vdev.  I am the principal developer.  I hope
you all don't mind me chiming in to provide a little bit more information.

First, I can't emphasize the "optional" qualifier enough regarding the
filesystem component vdevfs.  The hotplug daemon vdevd and the
libudev-compat library are meant to replace udevd and libudev respectively;
the filesystem is an add-on that can be used independently of whatever
device manager is running.  There are more detailed write-up's on the
design goals for each of the three vdev components in [0] and [1].

Second, I would like to point out that vdevd by itself is not too different
from mdev, nldev, and smdev.  The udev-like behavior comes almost entirely
from the shell scripts and auxiliary helper programs it executes in
reaction to device uevents.  I bring this up because these scripts and
helper programs could easily be ported to mdev, nldev, and smdev simply by
providing a wrapper that sets the appropriate environment variables (a
listing can be found in Appendix A of [2]).

Third, I would like to point out that libudev-compat is *not* dependent on
vdevd or any device manager.  A libudev-compat process receives device
events by watching for new files written into a well-defined directory in a
RAM-backed filesystem.  Vdevd simply runs a script to fill in /run/udev and
write device event files in order to communicate with libudev-compat
processes.

I'm happy to help test and evaluate vdev with Alpine.  This document [2]
contains a tutorial on how to try it out without installing, and what to
send me if something breaks.  We'll be making an alpha branch soon (see
[3]).

[0] http://judecnelson.blogspot.com/2015/01/introducing-vdev.html
[1] https://github.com/jcnelson/vdev/issues/32
[2] https://github.com/jcnelson/vdev/blob/master/how-to-test.md
[3] https://github.com/jcnelson/vdev/issues/33

Thanks,
Jude

--001a113f90482b0793051bbca2f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi everyone,<div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">
[vdev] a device manager with an approach a bit different, offers an<br>
optional filesystem interface that implements a per-process view of<br>
/dev. Possibly the least simple alternative, but interesting<br>
nonetheless.<br><br></blockquote><div><br></div><div>Thank you for your int=
erest in vdev.=C2=A0 I am the principal developer.=C2=A0 I hope you all don=
&#39;t mind me chiming in to provide a little bit more information.</div><d=
iv><br></div><div>First, I can&#39;t emphasize the &quot;optional&quot; qua=
lifier enough regarding the filesystem component vdevfs.=C2=A0 The hotplug =
daemon vdevd and the libudev-compat library are meant to replace udevd and =
libudev respectively; the filesystem is an add-on that can be used independ=
ently of whatever device manager is running.=C2=A0 There are more detailed =
write-up&#39;s on the design goals for each of the three vdev components in=
 [0] and [1].</div><div><br></div><div>Second, I would like to point out th=
at vdevd by itself is not too different from mdev, nldev, and smdev.=C2=A0 =
The udev-like behavior comes almost entirely from the shell scripts and aux=
iliary helper programs it executes in reaction to device uevents.=C2=A0 I b=
ring this up because these scripts and helper programs could easily be port=
ed to mdev, nldev, and smdev simply by providing a wrapper that sets the ap=
propriate environment variables (a listing can be found in Appendix A of [2=
]).</div><div><br></div><div>Third, I would like to point out that libudev-=
compat is *not* dependent on vdevd or any device manager.=C2=A0 A libudev-c=
ompat process receives device events by watching for new files written into=
 a well-defined directory in a RAM-backed filesystem.=C2=A0 Vdevd simply ru=
ns a script to fill in /run/udev and write device event files in order to c=
ommunicate with libudev-compat processes.<br><br>I&#39;m happy to help test=
 and evaluate vdev with Alpine.=C2=A0 This document [2] contains a tutorial=
 on how to try it out without installing, and what to send me if something =
breaks.=C2=A0 We&#39;ll be making an alpha branch soon (see [3]).<br><br>[0=
]=C2=A0<a href=3D"http://judecnelson.blogspot.com/2015/01/introducing-vdev.=
html">http://judecnelson.blogspot.com/2015/01/introducing-vdev.html</a><br>=
[1] <a href=3D"https://github.com/jcnelson/vdev/issues/32">https://github.c=
om/jcnelson/vdev/issues/32</a><br>[2] <a href=3D"https://github.com/jcnelso=
n/vdev/blob/master/how-to-test.md">https://github.com/jcnelson/vdev/blob/ma=
ster/how-to-test.md</a><br>[3]=C2=A0<a href=3D"https://github.com/jcnelson/=
vdev/issues/33">https://github.com/jcnelson/vdev/issues/33</a><br><br>Thank=
s,</div><div>Jude</div></div></div></div>

--001a113f90482b0793051bbca2f3--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---