Re: [DNG] vdev - the next generation

[aiitor_czr]

On 10/11/2016 02:00 PM, Ralph Ronnquist  wrote:

Good documentation is the next best thing.

Yes, i think so :)

  Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - the next generation

[Ralph Ronnquist]

Ralph Ronnquist wrote on 09/10/16 10:54:

I've now uploaded a first beta, vdevd_2.0, that includes the mechanism
for dealing with (hand) compiled udev rules, and also includes the
scanner rules and modem mode switching rules


Working version is vdevd_2.0.2 ... for the moment

Now, in order for VDEV to be of use to us mere mortals, there needs to 
be better documentation. Although I like reading documentation, and know 
how to enjoy well-documented functionality, I'm not especially good at 
writing it. So this is a call for a technical writer, or anyone with 
comparable skills, to step forward and volunteer for the VDEV 
documentation page(s).


Presently there are a "man vdevd" page and a "man vdevd-actions" page. 
Neither is more than adequate, at best. Given the central function VDEV 
is supposed to take on, I think it needs to be quite well documented. 
Especially since any other function that wishes to include hotplugging 
aspects will need to integrate with it, and thus the developer(s) of 
that function will want straight-forward, to-the-point and accurate 
documentation.


In real life, I suppose they or we will want the push-button "my Udev 
rules" to "my Vdev rules" compiler, but that won't be available very 
immediately. Good documentation is the next best thing.


Also, though of lesser priority (in my mind), there's some drive towards 
end-user oriented documentation, since some end-user(s) may want to tie 
in their personal hotplug actions.


Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - the next generation

[Ismael L. Donis Garcia]

- Original Message - 
From: "Ralph Ronnquist" <ralph.ronnqu...@gmail.com>
To: <Dng@lists.dyne.org>
Sent: Saturday, October 08, 2016 7:54 PM
Subject: Re: [DNG] vdev - the next generation


> I've now uploaded a first beta, vdevd_2.0, that includes the mechanism 
> for dealing with (hand) compiled udev rules, and also includes the 
> scanner rules and modem mode switching rules. The mechanism is just a 
> straight-forward (extended) use of the "hwdb" database, which already 
> was set up to hold properties keyed by device identification 
> (essentially vendor+product). So I added a helper that processes these 
> properties, and e.g, sets group ownership to "scanner" when the device 
> has the property "GROUP=scanner".
> 
> This only affects the vdevd package, which now is version 2.0, and 
> otherwise you'd use the latest libudev1-compat_1.2.1 and 
> vdev-initramfs_1.2_5.
> 
> If you are keen you should touch "/root/ralph.log", and then vdevd will 
> drop log pearls from the helper script "/lib/vdev/compiled.sh" into it 
> when devices are added. This particular feature will of course be 
> removed at 2.1.
> 
> With that mechanism and it's pre-seeding, vdevd is essentially ready, 
> and so is libudev1-compat (although I haven't really plunged into that 
> bath yet, so I don't know for sure).
> 
> However, vdev-initramfs still needs attention. At the moment it combines 
> initramfs building of vdev in competition with udev, and the set up for 
> sysvinit, also in competition with udev. (The latter of course only 
> makes sense where sysvinit is used, and maybe it should be separated 
> out. But then one would need two hands to manage the udev competition, 
> and it'd double (or more) the possible strange failure cases, and my 
> work load)
> 
> Note that the start/stop script in /etc/init.d/vdev still belongs to the 
> vdevd package, which thus also shows preference for sysvinit. But, if 
> you don't want vdevd in the initramfs (who does, really?) and/or have a 
> different init scheme, you should skip installing the vdev-initramfs 
> package, and with some manual blessing you'll easily get the vdevd magic 
> happening where you need it.
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

Thank you very much. Your work is dear for us all since it is vitally important.


| ISMAEL |

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - the next generation

[hal]

Ralph Ronnquist wrote on 10/08/2016 06:54 PM:

> With that mechanism and it's pre-seeding, vdevd is essentially ready, and so 
> is libudev1-compat (although I haven't really plunged into that bath yet, so 
> I don't know for sure).


Thanks so much for all your work on this!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - the next generation

[Ralph Ronnquist]

I've now uploaded a first beta, vdevd_2.0, that includes the mechanism 
for dealing with (hand) compiled udev rules, and also includes the 
scanner rules and modem mode switching rules. The mechanism is just a 
straight-forward (extended) use of the "hwdb" database, which already 
was set up to hold properties keyed by device identification 
(essentially vendor+product). So I added a helper that processes these 
properties, and e.g, sets group ownership to "scanner" when the device 
has the property "GROUP=scanner".


This only affects the vdevd package, which now is version 2.0, and 
otherwise you'd use the latest libudev1-compat_1.2.1 and 
vdev-initramfs_1.2_5.


If you are keen you should touch "/root/ralph.log", and then vdevd will 
drop log pearls from the helper script "/lib/vdev/compiled.sh" into it 
when devices are added. This particular feature will of course be 
removed at 2.1.


With that mechanism and it's pre-seeding, vdevd is essentially ready, 
and so is libudev1-compat (although I haven't really plunged into that 
bath yet, so I don't know for sure).


However, vdev-initramfs still needs attention. At the moment it combines 
initramfs building of vdev in competition with udev, and the set up for 
sysvinit, also in competition with udev. (The latter of course only 
makes sense where sysvinit is used, and maybe it should be separated 
out. But then one would need two hands to manage the udev competition, 
and it'd double (or more) the possible strange failure cases, and my 
work load)


Note that the start/stop script in /etc/init.d/vdev still belongs to the 
vdevd package, which thus also shows preference for sysvinit. But, if 
you don't want vdevd in the initramfs (who does, really?) and/or have a 
different init scheme, you should skip installing the vdev-initramfs 
package, and with some manual blessing you'll easily get the vdevd magic 
happening where you need it.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - the next generation

[Robert Storey]

Just want to say Ralph that your work on this is really appreciated. I
consider vdev to be one of the most important projects going. I wish I was
more competent at development work, because I'd like to help with it. When
you get to scanner support, I'm going to definitely get more involved with
testing and reporting. I make heavy use of my scanner, so I can give it a
good workout.

cheers,
Robert
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] vdev - the next generation

[Ralph Ronnquist]

Given that little has been mentioned abot vdev lately, I thought to drop 
this FYI to report were I am at on this.


Basically, my vdev packaging project reached it's first milestone some 
two weeks ago, of being installable and usable on Devuan 1.0.0 beta. 
That means, that if you have a Devuan 1.0.0 beta, you can install the 
packages for using vdev, but, by including a handy script, you can 
alternate between it and the original udev (with reboot in between).


Thus, it doesn't fully commit to using vdev by replacing udev.

I believe these packages will be included in "unstable" soonish. Until 
then you'll have to do manual download and install from

   https://git.devuan.org/ralph.ronnquist/vdev

Now I'm looking towards the next generation of vdev. The vdev software 
is complete in terms of machinery, but incomplete in terms of dealing 
with the full range of possible devices. In particular, it doesn't do 
usb_modeswitch for modem dongles, and it doesn't know much about 
scanners. About half of the udev deal with those.


To that end, I've been exploring the udev rule set in Devuan 1.0.0 beta. 
There are nearly 2800 different rules, with many rules specific for 
particular devices, and some rules spanning ranges of devices. However, 
there are only a handful of different "actions" happening for them, 
including both the installation into the /dev tree with appropriate mode 
settings, and some initial device control.


I intend to "compile" that into vdev by separating out the 
classification aspect, so as to install that directly into the hwdb 
properties. Then I'll add the few additional vdev actions needed based 
on those hwdb properties.


That should cater for most of the possible devices. The compilation work 
will be done by scripting under manual guidance, simply because there 
are too many variations in the udev rule authoring to allow a fully 
automated process. (For some of them you really need to hold your breath 
while processing them)


In practice, it'll mean to produce additional input files to the hwdb 
generation, with additional properties for devices as identified by the 
hwdb key.


Realistically I won't have this ready until late October. Until then, 
all and any feedback on the current packages is appreciated.


Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng