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