Rainer Weikusat <rweiku...@talktalk.net> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
