:: Re: [DNG] if2mac init.d service for…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: tito
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] if2mac init.d service for persistent network interface names
On Sat, 19 Dec 2020 15:10:01 +0100
Didier Kryn <kryn@???> wrote:

> Le 18/12/2020 à 17:26, Hendrik Boom a écrit :
> >
> > https://wiki.gentoo.org/wiki/Mdev says:
> > In general, when using KDE or GNOME, mdev is not suitable.
> > but does not explain why.
> > I surmise that KDE and GNOME have some specific involvement with
> > udev.
> >
>     AFAIU, Xorg uses libudev to retrieve information on devices. This
> can be worked around by providing Xorg with config files like in the
> old times, which is kind of a pain. This is the only thing which held
> me back from switching to Mdev a few years ago.
>
>
> Le 18/12/2020 à 20:25, aitor a écrit :
>
> > On 18/12/20 20:03, Joel Roth via Dng wrote:
> >
> >> And what about Jude Nelson's vdev? I, for one, would donate
> >> to support development of these lightweight udev alternatives.
> > Last lime i built vdev was at the very beginning of 2019 under
> > devuan testing (beowulf) before the conferences.
> > And It worked after doing some minor changes in the code. Maybe i
> > can recover this work.
>
>     I have followed the development of Vdev by Jude Nelson, but, at
> some point, I got frightened by the forest (dozens) of shell scrips
> which implemented the actions to perform when devices were
> installed/removed.
>
>     I think that, like in the case of Mdev, the biggest difficulty is
> in emulating libudev, which requires in particular to maintain an
> up-to-date database of devices. Jude has done a complete job and
> libvdev provides this emulation, but who maintains the database ?

Hi,
is this a database generated at runtime about the devices of the
current machine or just a collection of hardware ids/info?
In the latter case couldn't we let the udev/systemd people do the
work and use their database?

Ciao,
Tito

>     Another issue with emulating libudev is that it implies to
> continuously run after Udev and Systemd. I lean to think it would be
> nicer to have a simpler and stable API. Though I confess I have none
> in mind (~:
>
>     Cheers.
>
> --         Didier