If vdev can prove itself as viable as a full udev alternative with backwards compatibility to udev reliant software, you may have Slackware customers as well... maybe even more.

If and when. Let me quote what Anthony G. Basile posted yesterday in the eudev mailing list:So don't hold your breath

I suspect that the use of FUSE would be the last/first straw against wide adoption of vdev. I think the most realistic thing would be to simply fork the old udev code base. I have always wondered why the eudev devs simply follow the upstream udev/systemd at all. In the end, it's not really udev functionality which determines whether to go with systemd or not. The logind and IPC (dbus/kdbus) functionality seems more pivotal. I still use an older version of udev as it does what one wants without much fuss. The trouble with udev was always the rule syntax and especially its' ever-changing nature.

1 members found this post helpful.

So it uses FUSE... It's just another method to implement a device manager using existing tools and methodologies. If you look at the design of kdbus' virtual filesystem, it uses a filesystem layout as well. Vdev uses a virtual filesystem, but doesn't rely on dbus to implement it. It uses a different yet equally effective method. If FUSE is part of that, so be it.

https://github.com/gregkh/kdbus/blob/master/fs.c

Yes eudev is a stop gap, but kdbus was the key to systemd being pushed, and that hasn't happened yet Didier, and honestly, when it will happen is anyone's guess since the kdbus kernel patch code submission was withdrawn. Even the Gentoo developers said eudev was temporary at best. All eudev is, is a pre-extracted systemd-udev implementation. It's not a true fork. Forking the code is not the solution. Udev is severely undocumented at the API level. Nobody knows exactly how it works which is the problem. The best alternative is, or was, to build a new device manager from the ground up that can be documented, and vdev is that.

Give this guy a chance. At least he's willing to take suggestions and listen to downstream. How often is a developer willing to work, much less cater, to a community, take suggestions openly, and isn't involved with some major corporation with an agenda? Anthony is just skeptical, because existing solutions like mdev and hotplug2 did not deliver a full solution. Mdev was only a partial solution because it still needed other software to be fully functional. Hotplug2 never materialized outside of the wrt projects. Vdev is getting off the ground and inventing itself as a solution which uses existing methods, radically, but effectively by not requiring extras folded in to gain functionality. Give it time and let it at least get out of ALPHA status and into working BETA before drawing conclusions towards it's viability. We could at least be supportive and helpful in the least

3 members found this post helpful.

I'd be curious to know why you think so. Most UNICES have a FUSE implementation these days, and the API is very stable. Also, exposing application information as a filesystem (as opposed to, for example, a DBus API) gives three key advantages:
* everyone already understands filesystem semantics;
* filesystem semantics are sufficiently expressive for building general-purpose APIs (i.e. any program method can be represented by a directory tree; any method call can be decomposed into a sequence of file operations);
* filesystem servers naturally compose with existing programs, since the contact points between them are files.

I should also point out that if FUSE bothers you, I'm open to adding a 9P backend to fskit (the toolkit vdev is built with) as an alternative. I didn't go with 9P initially since I'm not familiar enough with it--specifically, I don't know if 9P offers a reliable way to get the calling process's PID, and I don't know about 9P's availability on other UNICES.

For what it's worth, I promise this won't be the case with vdev . I don't have time to go re-write vdev's config file syntax willy-nilly, and I avidly subscribe to the "don't break userspace" philosophy of system development.

I've been scratching my head as to why mdev/nldev/hotplug2 didn't catch on, since the reasons will probably apply to vdev as well. It's my understanding that these programs are quite simple--they basically listen to the kernel for netlink packets and run helper programs to handle each packet. The helper programs take care of creating and setting up the device nodes, loading modules, loading firmware, adding symlinks, etc. I guess this outsources too much functionality, thereby leading to duplicated code and inconsistent helper behavior? Maybe there are other reasons, like no libudev compatibility?

1 members found this post helpful.

So, I took some time to write up a design document here: http://judecnelson.blogspot.com/2015...cing-vdev.html. I'd love to hear your feedback, especially if you think there are some cases I haven't covered, or if you have any insights on how to approach alpha and beta release goals. Thanks again!

2 members found this post helpful.

I'm afraid that my knowledge be widely insufficient to give you an useful feedback, nevertheless thanks for the document that is insightful to what you want and plan to do.

Speaking as a Slackware user, of course the easier it would to be integrate vdev into a Slackware system the better chances it would have to be adopted - even more if it should be considered as drop-in replacement of existing components of the system. And maintainability on the long term is of course a major concern. But I'm stating the obvious, so sorry for the noise

Oh and I suggest that you open a new thread about vdev, so that it gets the exposure it deserves.

Didier Spaier has already expressed my own thoughts.

One minor quibble with your document. I would like to suggest that you use 'arbitrate' rather than 'equivocate'.

I'm not disputing your statement, but would be interested in hearing what constitutes a "full solution". My experience with udev is limited to troubleshooting network device driver problems. What does it do, other than figure out which device drivers a system needs and load them?

It does a lot of things:
* it adds/removes the device nodes and sets the appropriate ownership/permissions;
* it generates persistent device paths (by calling other programs);
* it queries devices for vendor information, which it remembers for rule matching;
* it adds/removes device node symlinks and directories;
* it offers a hardware database and querying tools to access it;
* it offers an API (libudev) for programs to query devices and react to events;
* it sets up kernel device parameters like disk polling intervals;
* it takes over a good chunk of what HAL used to do.

I'm sure there are others that I haven't mentioned; this is just off the top of my head.

2 members found this post helpful.

That summarizes the situation very well.
Although FUSE is available on most platforms, is painfully inefficient in current implementations, partially caused by its design itself. Just adds redundant cruft/layer.
Forking udev and stabilizing its ABI would be the way to go. Upstream applications which up to now anyhow rely directly on udev have already the code written, no need to do additional work to adapt to another system.
Obsoleting standalone dbus is even a more serious affair, affecting all desktop development. It's a similar situation to udev, forking and keeping the latest stable branch updated would be wise. There is a lot of software which does work with it, most non-Linux systems like DragonFly/Free/Net/Open BSDs rely on it. The term of kdbus adoption by Linux kernel is uncertain, but is likely to be merged one day and that would mean effectively desktop devs would be left at the mercy of systemd <-> kdbus path as rewriting lots of code originaly relied on dbus to another IPC would be unbearable.
All attempts to emulate systemd ABI like uselessd and various -shims are counterproductive as only strengthen the systemd position so upstream devs would have more and more reasons to count with it as the main dependency and more adjust theirs development to it.

Hi dunric,

Regarding FUSE performance, you'll be pleased to know that for special files, FUSE is not on the critical path at all. With device files in particular, the kernel (not FUSE) handles all data transfers between userspace and the device driver. In general, FUSE file servers only service requests for directories, file metadata, and regular file data. AFAIK, this is true for every filesystem, including the FUSE VFS kernel module, since this is how the VFS is implemented in all modern UNICES--the kernel device open(), read(), write(), and ioctl() syscalls via driver-specific code paths, not the VFS implementation (same goes for named pipes and UNIX domain sockets, which have their own code paths outside the VFS).

In vdev's case, this means that FUSE is only involved in opendir(), readdir(), closedir(), stat(), and access(). Granted, there are two rounds of switches in using vdev (app --> kernel (FUSE VFS) --> vdev --> kernel (FUSE VFS) --> app) versus the single round for udev and static dev (app --> kernel (/dev) --> app), but this is actually faster than the three rounds of context switches needed to achieve the same functionality with systemd-logind (app --> kernel (kdbus or UNIX domain socket) --> systemd-logind --> kernel (/dev) --> systemd-logind --> kernel (kdbus or UNIX domain socket) --> app).

I'm creating vdev because I want per-process device node access control in a portable manner. Short of creating a specialized devfs for the kernel or rewriting everything to use a new specialized device access API, this is the most efficient way I know of for doing it. I'm all ears if you know of a better way

Offering a full solution meant that anything as an alternative to udev must do all the work of udev. Either it does everything udev does or it's just another, pardon the meaning, halfassed solution.

Mdev from Busybox came with a devfsd-like design but offered some aspects of creating device nodes dynamically but it could not load drivers dynamically for devices when devices were attached to the system. The option was to use hald to use hald's rule sets to assign and load drivers using a secondary daemon system combined with the kernel hotplugging system and mdev to function as a pseudo-udev, but still when one critical key component is classed as deprecated, it's not a feasible design in the long term since hald is only in maintenance mode with very little done other than patches being made. Not to mention hald's API is completely different from udev and event based drivers are left non-functional.

Hotplug2 was in openwrt, but little was known about it. Other than that, I think it's design and function was similar to mdev and still limited in functionality.

If vdev can offer dynamic device nodes, dynamic driver loading, rule based handling, but also remove and delete nodes if no longer in usage, and provide a working solution that effectively supplicants udev, or even replaces it, then it is a solution.

The problem of kdbus is still an unknown, even at this point it's adoption is still unknown, and had been speculated for last year, but even then having a working alternative to udev due to fact kdbus' handling was integrated into systemd, means a viable alternative will be needed in case a stand-alone kdbus handler can not be created.

If vdev can meet or even beat expectations then this will be a solution for not just Linux, but any UNIX and UNIX-like system out there, and having options that not only work but are reliable and feasible are needed to have growth in operating systems rather than stagnation.