[svlug] Inits (was: On the process of picking up systemd)

Akkana Peck akkana at shallowsky.com
Sat Jan 17 17:27:21 PST 2015

Rick Moen writes:
> At the time, I said that /etc/udev/rules.d/70-persistent-net.rules is
> 'obviously intended to ensure that a specified MAC address always ends up as
> eth0' on the described system.  That file says:
> # PCI device 0x8086:0x100e (e1000)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:aa:b2:05", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> However, shortly after posting that, I realised that it's not quite that
> simple.  The cited plumbing appears to say to udev 'Any time you receive a
> uevent from the kernel letting you know that the kernel heard from the PCI
> controller chip that MAC address 08:00:27:aa:b2:05 has been spotted, create
> add an eth0 special-file node to /sys/class' -- or something like that.[1]

Yes, that also my understanding of what the rule is doing.

> That having been said, I'm still not sure how that ensures that the kernel 
> addresses the device as eth0.  Do you happen to know, Akkana?  I really
> don't.

In other words, how does it get from NAME="eth0" to network
libraries getting packets through a specific piece of hardware,
considering it's not creating a /dev node? If so ... no. I've never
been clear how that works, and I don't think it has anything to do
with /sys/class nodes because I'm pretty sure networking libraries
worked pretty much like they do now long before /sys/class even
existed in the kernel.

I've never found a good description of how that works, and people
I've asked either understand it at the user/library level (where I'm
at) or at the deep kernel "I'm writing a new networking driver"
level, and few people seem to know much about how those two levels
talk to each other or why network drivers don't create a /dev node
like nearly every other type of device driver.

> I've been tempted to deliberately lose udevd and /sys from server builds on
> a theory of 'this looks like avoidable complexity not needed in my usage
> scenario', but I'd like to figure out in advance what if anything would ever
> break and under what conditions.

I found out a while back that if you get tired of the constantly
changing udev rules syntax, you can make a static device in
/lib/udev/devices and it will persist across boots ...
... but of course that wouldn't help with network devices that
don't use /dev nodes. Also, that was 2011 so it probably doesn't
work any more anyway, udev being udev.

> > I'm sure there are other, thornier problems where a dependency-based init
> > really is the best fix.
> Quibble:  I think you mean event-based, here (rather than dependency-based).

Yes, that would probably have been a better way to say that.


More information about the svlug mailing list