[lfs-support] "Interesting" Names

Dan McGhee beesnees at grm.net
Tue Nov 26 09:03:44 PST 2013

On 11/26/2013 07:53 AM, William Harrington wrote:
> On Nov 25, 2013, at 8:06 PM, Dan McGhee wrote:
>> There were many allusions to the "new naming convention."  enpxx for
>> ethernet and wlpxx for wireless.  Where does this name convention
>> exist?  I remember that xlnglp posted about what he had discovered in
>> the "different" names, but I can't find what he wrote.  I don't
>> remember
>> if he had identified a source.
> Possibly it came from here: http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
> Check out biosdevname
> Sincerely,
> William Harrington
Thanks, William. That link led down an interesting path. It appears that 
this "name thing" originated at Dell. I don't know if the fellow who 
came up with the idea is a maintainer for UDEV or not. Anyway, The above 
link led me to this:


It is an interesting discussion on how to implement or cancel the "name 
thing" in udev. This, and William's suggestion, led me to "biosdevname." 
It is a utility to take a kernel device name and return "the BIOS-given 
name it 'should' be." (That from the biosdevname man page.) 
[semi-rant]There is no indication of the identity of the "true BIOS name 

Also from the biosdevname man page:

> The *physical* policy is the current default. However, when invoking 
> biosdevname in udev rules, one should always specify the policy you 
> want, as the default has changed over time.
> The *physical* policy uses the following scheme:
> em<port>[_<virtual instance>]
>     for embedded NICs 
> p<slot>p<port>[_<virtual instance>]
>     for cards in PCI slots
> The
>     *all_ethN* policy makes a best guess at what the device order
>     should be, with embedded devices first, PCI cards in ascending
>     slot order, and ports in ascending PCI bus/device/function order
>     breadth-first. However, this policy /does/ not work if your PCI
>     devices are hot-plugged or hot-pluggable, including the virtual
>     functions on an SR-IOV device. In a hot-plug scenario, each
>     separate udev instance will be invoked in parallel, while the
>     device tree is still being populated with new devices. Each udev
>     instance will see a different PCI tree, and thus cannot provide
>     consistent enumeration. Use of this policy should be limited to
>     only scenarios where all PCI devices are present at boot (cold-plug).

So, it appears that this "name thing" is a "udev thing" and not a 
"kernel thing." If my conclusions are correct, then I still wonder why 
Alan's NIC, which is the same as mine, got a different name. The only 
difference I know of so far is that he used LFS_SVN and I used LFS-7.4. 
I'm discounting the kernel difference. I don't know if there's any 
difference in results between UDEV-206 (LFS-7.4) and UDEV-208(LFS-SVN). 
The only other possible difference is that Alan may have added "UDEV 
Extras from BLFS.

On the other hand, I can understand another possible difference unless I 
don't understand what "hot-plug" means. To me it's the ability to "plug 
something in" while the computer is running and have it work--much like 
a USB device. If my NIC is hot-pluggable, I would have to open the 
laptop case to remove it.

Also, in the last 3-4 months, I've not seen anyone encounter this 
situation but Alan. Does it exist in LFS, as written, yet?

I personally don't care what my NIC is named. I just want to be able to 
make it work if it doesn't.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20131126/0492b8e0/attachment.html>

More information about the lfs-support mailing list