Hi and thanks for the feedback!

> With respect to the ingenuity and determination of the author, something
like vdev is not really something that I expect to succeed, nor would I
particularly recommend that others use it. What he (assuming male with
the name of Jude) is trying to do is commendable, but ultimately
self-defeating because:

I will consider vdev a success if I can use it in place of udev on Debian
GNU/Linux, Debian GNU/kfreebsd, and OpenBSD (operating systems I use
regularly). I will of course accept and help test patches to add other
*nix. Also, you're correct--I'm male :) My name is pronounced the same as
it is in "Hey Jude" by the Beatles.

> 1) The license is GPLv3, which I would not touch with a 50 foot pole,
neither will anyone else, BSD or otherwise. No one is going to port it
under those conditions.

I'm open to GPLv3/ISC dual licensing, if there is sufficient interest. My
subnotebook runs OpenBSD, for instance, and OpenBSD is my next porting
target after Linux. However, I don't know the correct legalese to say
something to the effect of "the OpenBSD version of vdev is ISC-licensed,
and the Linux version of vdev is GPLv3-licensed." Maybe you or someone
here can point me in the right direction?

> 2) It is dependent on his personal projects.

Well, either fskit and libpstat can be internal to vdev, or they can be an
external projects, so I don't see why the distinction is relevant. In
fact, fskit was spun off from Syndicate (
https://github.com/jcnelson/syndicate), which has been in use for years.

> 3) It is using fuse, which can be quirky.

I've been developing with FUSE continuously for the past 4.5 years, so I'm
not sure what quirkiness you're referring to (perhaps I'm too used to them
to think of them as quirks?).

* If you're referring to I/O performance, then there's nothing to worry
about in vdev's case, since the kernel (not FUSE) handles device node I/O.

* If you're referring to supporting inotify()-like behavior (something FUSE
doesn't do either), you'll be pleased to know I have a solution. Instead
of a workflow like "(kernel) device state changes --> (kernel) send message
via netlink --> (vdev) parse netlink message --> (vdev) update filesystem
state", vdev will have a workflow more like "(kernel) device state changes
--> (kernel) send message via netlink --> (vdev) add netlink message to
task queue--> (vdev-taskqueue) issue mknod() or unlink() --> (kernel-VFS)
wake up inotify listeners --> (kernel-FUSE) --> send mknod() or unlink()
--> (vdev) update filesystem state". This ensures that device state
changes result in inotify listeners getting woken up (as they would be with
udev), in addition to ensuring the device node appears or disappears.

* If you're worried about vdev crashing and leaving a "dangling
mountpoint," I already have a watchdog written that can clean it up, log
the failure, and respawn vdev (I use it for Syndicate).

* If you're worried about testing and debugging vdev, you'll be pleased to
know that it can run concurrently with udev, on any mountpoint you want.
You can even run multiple instances of vdev independently.

There is a HUGE advantage to using FUSE that I think outweighs the quirks:
you get per-process access control for free, since FUSE tells you which
task ID issued the request (which vdev uses to query the calling process
and filter device nodes accordingly). This is much simpler than
systemd-logind's approach, which has to authenticate the calling process
itself, open the device file descriptor, and send it to the calling process
via dbus (thereby requiring the calling process to speak dbus and link
against systemd-logind's dbus interface).

> 4) By using libstdc++ and STL that means that he is using C++. I have
nothing against C++, but it is not usually used for system development
outside of Windows. Why? Because C++ requires the compiler to use name
mangling, which has never been standardized. This means that everything
linked against or uses vdev has to maintain the same ABI as the version of
vdev you happen to be using. Should you change anything you end up with
unpredictable behavior. You would have to update everything all at once,
ala Windows-like updates.

Nothing would ever need to link against vdev. I have no intention of
creating a "libvdev" like there is for libudev--I would rather invest the
time into making the vdev filesystem interface sufficiently expressive to
obviate the need for a dedicated library.

fskit is the bigger concern, since both vdev and runfs (another project)
link against it. I'm in the process of making the public fskit API
declared as 'extern "C"' to remedy this.

Hope this helps,
Jude


On Wed, Dec 17, 2014 at 2:36 PM, Go Linux <dmarc-noreply@???>
wrote:
>
> FYI. Some feedback on vdev.
>
> --- On Wed, 12/17/14, T.J. Duchene <t.j.duchene@???> wrote:
>
> > From: T.J. Duchene <t.j.duchene@???>
> > Subject: Re: [Dng] system scriptinng language.
> > To: "'Aldemir Akpinar'" <aldemir.akpinar@???>, dng@???
> > Date: Wednesday, December 17, 2014, 1:12 PM
> >
> > On 17 December 2014 at 00:37, Go Linux <golinux@???> wrote:
>
> > On Tue, 12/16/14, Enrico Weigelt, metux IT consult <
> enrico.weigelt@???> wrote:
>

> >>>    Subject: Re: [Dng] system scriptinng language.
> >>>   To: dng@???
> >>>    Date: Tuesday, December 16, 2014, 2:37 PM

>
> >>> What would you suggest as udev replacement ?
> >>>
> --------------------------------------------
>
> >> The workings of udev are a mystery to me. But this option was posted
> on the modular-debian list. Have no idea whether >> it would be useful.
> Just providing information.
>
> >> http://www.freelists.org/post/modular-debian/Announcing-vdev
>
> > Vdev sounds really interesting. One of the main goals is that, it wants
> to be portable across the *nix universe, which is very > good for freedom
> of choice. I will definitely try and see how it performs.
>
>
> With respect to the ingenuity and determination of the author, something
> like vdev is not really something that I expect to succeed, nor would I
> particularly recommend that others use it. What he (assuming male with
> the name of Jude) is trying to do is commendable, but ultimately
> self-defeating because:
>
> 1) The license is GPLv3, which I would not touch with a 50 foot pole,
> neither will anyone else, BSD or otherwise. No one is going to port it
> under those conditions.
>
> 2) It is dependent on his personal projects.
>
> 3) It is using fuse, which can be quirky.
>
> 4) By using libstdc++ and STL that means that he is using C++. I have
> nothing against C++, but it is not usually used for system development
> outside of Windows. Why? Because C++ requires the compiler to use name
> mangling, which has never been standardized. This means that everything
> linked against or uses vdev has to maintain the same ABI as the version of
> vdev you happen to be using. Should you change anything you end up with
> unpredictable behavior. You would have to update everything all at once,
> ala Windows-like updates.
>
> So thanks, but no thanks. I have a couple of other reasons, I wouldn't
> use this, but I don't really have time right now to go over them.
>
>
>
>