Greetings.

On Mon, 27 Jul 2015 13:16:35 +0200 Jude Nelson <judecn@gmail.com> wrote:
> I'm guessing you're not on the alpine-devel list?  If not, then my reply to

I am not. I already have to deal with too many mailinglists. And web
interfaces to mailinglists suck.

> your earlier message to alpine-devel might be of interest to you insofar as
> getting started with libudev-compat.  Apologies if this is a repeat message.

Thanks for pointing it out.

> ---------- Forwarded message ----------
> From: Jude Nelson <judecn@gmail.com>
> Date: Sun, Jul 26, 2015 at 11:09 PM
> Subject: Re: [alpine-devel] udev replacement in Alpine Linux
> To: alpine-devel@lists.alpinelinux.org
> 
> 
> > From: Christoph Lohmann <20h_at_r-36.net>
> > Date: Sun, 26 Jul 2015 12:10:26 +0200
> 
> Hi Christoph,
> 
> > 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
> needed.
> 
> 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 [0].
> 
> > 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
> forked).
> 
> The filesystem add-on uses a couple C++ STL containers at the moment, but a
> C rewrite is in progress (see [1]).  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).

Please,  ban all C++ off your life. You only made mine more miserable by
having to rip off what you did wrong in your past life.

Off  to work. The idea is spreaded. I will be happy to see you all send‐
ing patches for smdev. There we can discuss the  implementation  details
on every patch in hackers@suckless.org.

> [0]
> libudev-compat communication:
> *
> https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/event-push.sh
> *
> https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/event-put.c
> * https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/subr.sh
> *
> https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/subr-event.sh
> *
> https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/udev-compat.sh
> 
> libudev-compat hardware database:
> *
> https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/hwdb-props.sh
> * https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/hwdb.sh
> *
> https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/subr-hwdb.sh
> * https://github.com/jcnelson/vdev/blob/master/hwdb/gen_database.sh

I  will  take  all the useful features and leave the rest of the corpese
lying there.

> [1] 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

Stop  writing such wrappers. Make it a simple C file that can be reused.
Gtk+ and glib should be an example for all of us how to not  name  func‐
tions and how to not add complexity on first sight of feature.

And  again: Please make this world a better world by not using C++ again
in any project. It will make it useless for future generations.


Sincerely,

Christoph Lohmann



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---