On 11/26/2013 11:23 AM, Bruce Dubbs wrote: > 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. > You're right, Bruce. I had my tongue in my cheek when I wrote what I did about "hotplugging." From reading that "policy statement" in the man page, I think my NIC should also be named "enpXsY" but it's "eth0." Like I've said, I really don't care. These are just dots that don't quite connect for me, and I don't like "loose dots" hanging around. :)
Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
