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.
::
Re: [DNG] How to stop udev from re-…
