> From: Christoph Lohmann <20h_at_r-36.net>
> Date: Sun, 26 Jul 2015 12:10:26 +0200
> For compatibility reasons the libudev‐compat needs to be ripped
> off into a separate project so you don’t infect smdev with systemd code.
> The libudev compatibility is especially needed for X.org and dynamic
> uevent device discovery.
Feel free to fork mine if you'd like :) Please keep in mind that it is
LGPLv2, since it is forked from libudev.
> * Rip off libudev-compat from vdev and have it a separate package, if
You may also be interested in the scripts, auxiliary programs, and hardware
database vdevd uses to communicate with libudev-compat. Some of the more
relevant files are linked at the end of this email .
> Please don’t use vdev. It does not follow the KISS principles and uses
> C++. The namespace for gid/uid is a big hack which should be in the
> kernel, as it is in Plan 9.
Vdevd and libudev-compat are written in a combination of C and shell
(dash). If you want to be specific, vdevd is written in C99, while
libudev-compat uses some GNU extensions (hold-overs from when it was
The filesystem add-on uses a couple C++ STL containers at the moment, but a
C rewrite is in progress (see ). As mentioned earlier, the filesystem
add-on is wholly optional, and not needed for "normal" use--if all you want
from the vdev project is something to replace udev and libudev, then vdevd
and libudev-compat are sufficient (substitute vdevd with
nldev+mdev+mdev-script-to-vdev-script-wrapper as desired).
libudev-compat hardware database:
 The biggest blocker is the dependency libfskit. However, libfskit is
basically C with STL containers, and is being modified to use sglib-style
containers instead (i.e. the changes aren't significant). You can track
the progress here: https://github.com/jcnelson/fskit/issues/10
Received on Sun Jul 26 2015 - 23:09:31 GMT