Network interface renaming, where does INTERFACE_NAME get applied?

[Bill Nottingham]

Dan Williams (dcbw at redhat.com) said: 
> > > I see that initscripts in F18 ships this udev rule:
> > > 
> > > ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device",
> > > RESULT=="?*", ENV{INTERFACE_NAME}="$result"
> > > 
> > > I'm trying to tackle some problems related to interface renaming, and
> > > understanding how this works would be useful.
> > > 
> > > But I can't find which software component *applies* the INTERFACE_NAME
> > > variable set by the above rule, actually performing the interface
> > > rename. Can you explain?
> > > 
> > > FYI, I would imagine this area will also be susceptible to a current
> > > udev bug, https://bugs.freedesktop.org/show_bug.cgi?id=56929
> > 
> > IIRC support INTERFACE_NAME is gone for quite a while since udev stopped
> > to provide implicit permenanet naming since it was a trainwreck. People
> > should use biosdevname instead.
> 
> Which doesn't work for USB devices, in which case you have to write
> manual rules to do the rename.  And when you do, please make sure you
> rename the interface somewhere *not* in the kernel namespace, which
> means don't use "ethX", "usbX", "wwanX", "wlanX", etc.  Otherwise you'll
> race with the kernel when discovering network devices, and the rename
> will fail.

So what rename_device is trying to do here is to support naming specified
in the ifcfg files (i.e., admin-specified configuration). While it could
have issues while it's in the kernel namespace, it's best to at least try
and support it. I've committed (but not yet built) a patch to initscripts
so it will attempt to set the name here.

Bill