:: Re: [DNG] How to stop udev from re-…
Inizio della pagina
Delete this message
Reply to this message
Autore: Simon Hobson
Data:  
To: dng@lists.dyne.org
Oggetto: Re: [DNG] How to stop udev from re-ordering devices
Rainer Weikusat <rweikusat@???> wrote:

> This is published here in the hope that it is useful for someting.
>
> The basic design of udev is similar to that of a forking server: There's
> a parent process listening for uevents from the kernel on a netlink
> socket which passes these events to worker processes for actual
> processing. In case no idle worker process is found, a new one is
> forked, up to a configurable limit (=> udevd(8)).
>
>     One could argue if using more than one worker process is
>     actually sensible considering that uevent processing happens
>     mostly during startup and isn't going to take much time,
>     especially as this is a text book example of the simple, obvious
>     design one shouldn't be using if good performance is to be
>     achieved: The process which read the uevent from the socket is
>     already running and the CPU executing it has all the data in its
>     cache and kicking this to another CPU is a waste: The process/
>     thread which received the event should process it and another
>     should be listening for more uevents while this is happening.

>
> A less-than-desirable side-effect of this model is that uevents causing
> driver loads may end up loading the drivers in an order different from
> the one the uevents came in.


So it's suboptimal - perhaps why the systemd guys are so fond of it ! It also explains the "random" ordering that the systemd guys have "fixed" by making the names even more unfriendly.

Personally, I've always just edited /etc/udev/rules.d/70-persistent-net-rules* to give user-friendly names to my interfaces. Typically I use things like ethint, ethext, and so on - far better than trying to remember that eth0 is the internal port, eth1 is the outside, and so on.

* Don't know if that's "standard" or a Debian packaging thing.