[lfs-support] "Interesting" Names

Bruce Dubbs bruce.dubbs at gmail.com
Tue Nov 26 09:23:37 PST 2013

Dan McGhee wrote:
> 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:
> http://marc.info/?l=linux-hotplug&m=128892593821639&w=2
> 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
> giver."[/semi-rant]
> 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.

The difference could be the motherboard architecture or the slot the 
Ethernet is plugged into.

> 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.

There are such things as USB Ethernet adapters.  I'm not sure how useful 
they are today.  Perhaps some tablets have USB but not a Ethernet socket.

   -- Bruce

More information about the lfs-support mailing list