I found this at the bottom of https://devuan.org/newsletter_22dec.htmlhttp://www.commitstrip.com/en/2014/1...e-park-is-open

hehe... aint that the truth

Thank you very much for these links. I hadn't known about CommitStrip. Or about the shift from debianfork to devuan.

Cheers!

Did you guys see those new projects on devuan?

Vdev https://github.com/jcnelson/vdev
Loginkit https://github.com/dimkr/LoginKit

Loginkit seems like a wrapper for ConsoleKit2, but vdev... wow. Something totally different there.

Unfortunately, vdev is depending on libc++, which I find dreadful for an early-boot tool. It's also depending on a couple of other projects from the same author, so it may not be much lighter than the alterntative.

Wow, that comic captures the mood of this forum perfectly.

Hi gnashley, vdev author here. I use C++ only for the STL; my C++ style is otherwise very C-like, if this is a concern. I also take care to give all public symbols in my projects C linkage, so you don't have to worry about the compiler mangling them. I realize that vdev plus its dependencies is heavier than mdev, but I don't think it will be as heavy as udev when all is said and done (remains to be seen, of course, but truth be told I'm not trying to compete with mdev).

Given these constraints, I'd be curious to know what your concerns regarding my using C++ are (or any general concerns you may have, for that matter), so I can address them now instead of after a release.

Thanks!

6 members found this post helpful.

My question isn't about C++, as to me programming language is fickle here, but rather is vdev fully documented as far as the API is concerned to where people writing drivers to interact with vdev don't run up again an undocumented interface and aren't told what is or isn't going on with the system?

Hi ReaperX7, the plan is to have vdev expose its runtime state and API as part of its filesystem. I'm looking to avoid creating a DBus interface or a "libvdev," since filesystem/inotify semantics are sufficiently expressive for my purposes. The API directory hierarchy will of course be stable and documented.

Insofar as configuration, the vdev config files are ini-formatted, and each section and key will be stable and documented (there won't be that many--probably no more than 20 over its entire lifetime).

While I'm at it, I'll probably end up creating a "libudev-compat" library that maps the udev API onto vdev filesystem operations. A cursory look through the udev API suggests that this shouldn't be terribly difficult, but of course time will tell

2 members found this post helpful.

If it can also duplicate the gudev dependency some packages use, you'll have a ringer. The xf86-input-evdev driver will have to also be looked at for compatibility, but hopefully it'll pass, but we do have the stand-alone fallbacks, so no loss there.

All I can say is do the best you can, keep it simple, and write it so it does what its supposed to do, and does it well, and your efforts will be far reaching.

Hi ReaperX7,

Thanks for the feedback! I'll definitely keep it as simple as I can, and focused solely on curating an access-controlled view of all available devices.

Regarding gudev compatibility, it's my (limited) understanding that gudev is simply a GObject wrapper around libudev1. Do you know if this is the case? The reason I ask is because if I can create a libudev1-compat that's at least API-compatible with libudev1, then there won't be a need to write a new gudev-compat library (then, I'd just re-compile unmodified gudev against libudev1-compat to get gudev-compat).

gudev brings in glib2 to the list of dependencies. I package gudev separate from udev to avoid dependency on glib2 for early boot. I applaud your efforts judecnelson, but hope you will keep the tool as self-contained as possible. This is actually what I least like about systemd itself -the long list of dependencies starting right from the start of the init process.

Yes, the problem of feature creep also plagued it and still does, but as long as everything is self-contained and libudev and libgudev can be effectively wrapped to vdev's library compatibility layer, and everything is thoroughly documented, you'll have possibly the next-gen component Linux needs. You possibly could create a multi-usage libvdev_compat.so and have it symlinked to libgudev.so and libudev.so as needed as well to function with glib-2.x and gobject-introspection for gir-data needs.

Also, this is one reason upstream developers visiting communities, like LQ, is very well liked, especially when the developers are willing to listen, make reasonable adjustments, and bridge that gap between developers, system maintainers, and users.

I see this project going places, and I honestly like what I see. You can't say that everyday. I wonder when completed, if this could be picked up by other UNICES as well?

haha that comic gave me a good laugh. systemD(eath) jokes never tire.

At the time of this writing, there are only three dependencies outside of the usual suspects (libc, librt, libpthread, libdl, libm). They are libfuse, fskit (one of mine), and libpstat (another one of mine). Each of these is pretty self-contained--the only extra dependency needed beyond the usual suspects is libssl for libpstat, and this itself is negotiable, since libpstat only needs libssl for a SHA256 implementation.

I'm always happy to receive feedback, especially constructive criticism! I'd rather design problems away before a release instead of hacking them away after the fact, since the former usually takes a lot less effort. What better way to do so than by talking about it with the would-be users?

Looking at the dependency chains on my laptop (Debian), it looks like adding libudev-compat and libgudev-compat will probably make or break adoption (who'd have thought so many packages needed a library interface to udev?). I'll be sure to expose all of the relevant information these libraries need via vdev's filesystem, so making compatibility libraries won't be a major difficulty.

Regarding other UNICES, vdev, fskit, and libpstat are designed from the get-go to be portable. I'm aiming to port to FreeBSD and OpenBSD at least, since I use them (semi-)regularly. Well-written patches that add support for others (NetBSD, Solaris, etc.) will be gratefully accepted.

Full documentation will come once the interfaces stabilize a bit more. I'm about to release some alpha packages to get early feedback from the Devuan community; I'll take that opportunity to get some initial documentation going on the project's wiki to help would-be testers.

2 members found this post helpful.