On Mon, 20 Jun 2016 09:26:56 +0100 Simon Hobson <li...@thehobsons.co.uk> wrote:
> 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. Of all the escapades of FreeDesktop.Org, managers of Lennart and the Redhats, these name thingies are some of the least onerous. I put a shellscript on the list a few months ago that delivers the wifi device name, and that script can be used in init scripts and the like. I mean, by all means use it as a talking point, but if it's actually giving you trouble, look up my shellscript and use it. SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
