On Mon, 20 Jun 2016 09:26:56 +0100
Simon Hobson <linux@???> wrote:
> 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.
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
::
Re: [DNG] How to stop udev from re-…
