:: Re: [DNG] vdev - the next generatio…
Pàgina inicial
Delete this message
Reply to this message
Autor: Ismael L. Donis Garcia
Data:  
A: Lista de Devuan
Assumpte: Re: [DNG] vdev - the next generation
----- Original Message -----
From: "Ralph Ronnquist" <ralph.ronnquist@???>
To: <Dng@???>
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@???
> 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 |

========