Hello everyone,

I'm working on a portable device manager for *nix called vdev, and things are getting stable enough that I'm comfortable talking about it with potential users. When finished, I hope to use it to manage my /dev on Linux, FreeBSD, OpenBSD, and other UNICES. On my Linux installations, I hope for vdev to become a drop-in replacement for udev.

The key improvement vdev offers over udev is that vdev does per-process device access control. With vdev, different processes will see different views of /dev, and a process can only learn that a device file exists (let alone access it) if vdev allows it. Unlike similar features offered by ConsoleKit and systemd-logind, programs do not have to use dbus or a hypothetical "libvdev" to access privileged device files. Instead, vdev implements /dev as a userspace filesystem, allowing it to prevent unauthorized processes by equivocating about its device files.

I've written a design document here that describes vdev in more detail. I humbly invite the Slackware community for any comments, feedback, or criticisms it has, so I can "design away" problems now instead of hacking them away later.

The source code for vdev is here. It is dual-licensed under the terms of either the GPLv3+ or the ISC license.

Regards,
Jude

Hey Jude. Slackware is a good place to develop software and test things. The atmosphere here is fairly positive natured and due to how flexible the system is, chances are getting it working shouldn't be too painful. Eric Hameleers aka AlienBOB, and Robby Workman both are highly skilled package builders and know a great deal about the inner workings along with Patrick who runs the whole thing. I would suggest trying to get with them about anything specific about Slackware first.

I think a lot of the suggestions made in the previous topic about constructing a well defined compatibility layer for udev interfaces and dependencies were really all that mattered. As far as using FUSE and other things, using existing software in new ways is the best idea rather than forcibly reinvent the wheel for the sake of doing so.

You'll probably want to get familiarized with the Slackware Slackbuild script system as well as developing an init control file to start, stop, and restart things using Slackware's bsd-like sysvinit implementation. Slackbuilds.org has several templates as well, and Robby takes new projects in every so often. You may want to build your own packages first for testing purposes and if all goes well, getting it published on Slackbuilds.org would be a good stepping stone. Though it would probably take time to become official, if and when it did, everything would be already for immediate importing.

Hi ReaperX7,

Sorry if this came off as a double-post. I created a new thread on the recommendation that it would make it easier for the community to find (since the initial discussion was unrelated to the topic of the earlier thread).

Thank you again for your sound advice! I'll definitely create packages on my own first (doing that for Debian and Devuan), to lower the barrier to entry for initial testers.

2 members found this post helpful.