And if you're like me, you won't be content to blindly copy this rule without understanding what it all means. What are all those constants for? Why can't we go for the simpler example shown in Writing udev rules:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:00", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="foo"
What's wrong with that?KERNEL=="eth*", ATTR{address}=="00:00:00:00:00:00", NAME="foo"
Well, I don't know if it could be said that there's anything wrong with that rule (other than the fact that it is uselessly invoked for any other action), but it does lack precision; if there ever is, say, an "ethical" device that happens to have the same address attribute (maybe it is attached to the Ethernet port and inherited the attribute), it would also match that rule. Probably unlikely, but you never know.
Here's the first rule again, deconstructed:
ACTION=="add"
This shouldn't need any explanation. :)DRIVERS=="?*"
Ensures that there is a driver for this device (i.e. it is a physical device, not a virtual one).SUBSYSTEM=="net"
Provides a context for the following attributes (since there could be other subsystems with the same attribute names).ATTR{type}=="1"
Ethernet hardware type (defined in if_arp.h)ATTR{address}=="00:00:00:00:00:00"
MAC address, obviously :)ATTR{dev_id}=="0x0"
In case there are multiple devices with the same MAC address, this matches the first one.
I think that with all of the above, the KERNEL match is superfluous; although I guess it could be used to skip any interface that has already been renamed to something other than "eth*".
And now I can rest, contented. :)
1 comment:
Ainsworth Casino | JSTOR 9.5 - JetBlue
Ainsworth Casino offers slots and video 동두천 출장안마 poker machines, table 논산 출장안마 games and 김제 출장안마 more! Experience our 양주 출장샵 signature brand in a world where the possibilities 광주광역 출장안마 of Las Vegas
Post a Comment