I think I understand some of the problem. Here is how I understand things: Linux network drivers cannot decide the N in ethN when they scan for NICs. The kernel provides "add a network device" and "remove a network device" functions only. (I'm guessing here) Linux network drivers have no control over when they are initialized. The kernel decides which drivers are initialized and in what order. Linux network drivers are written by different developers, so the scanning algorithm and methods are different for each driver. One driver might search the PCI/PCIe address space from the bottom up while another might scan from the top down. Different kernel versions might call network driver initialization functions in a different order. A Linux system administrator might load and unload network drivers using 'rmmod' and 'modprobe'/'insmod' in random order. This means, if you have a Broadcom NIC on the motherboard and an e1000 NIC in a PCI slot, if the kernel calls the bcm->initialize() function first, then eth0 is the Broadcom NIC and the e1000 driver will be told that eth1 is the add-in NIC's device. On the other hand, if the kernel calls the e1000->initialize() function first, then eth0 is the add-in NIC, and the bcm driver will be given eth1 for the motherboard NIC. I don't think Linux network drivers have the ability to tell the kernel "I want this NIC to be eth0". The kernel decides what the next 'N' should be in 'ethN' when a driver says "hey, I want to add a network device to your already-existing list of network devices".
Matt said the proposed solution for the kernel was to reserve N "slots" for on-board devices. I can sort-of understand why it was rejected. What value of N is good enough? 2? 4? Someday a motherboard could have 8 NICs. Not to mention the non-linearity of ethN assignment that would result. Suppose N was 4. If you have a motherboard with 2 on-board NICs, then you'd have eth0 and eth1, but no eth2 or eth3. The first add-in NIC would be eth4. All scripts that search for all NICs in a system are designed to stop once they hit eth2 since it doesn't exist. They'd miss eth4. I don't really like the proposal either, but I don't see how to solve the real problem. Even if a network driver that detected that the NICs it owns are indeed the motherboard NICs and could "take over" eth0 from another network driver (moving the old eth0 to a new location like eth3, for example, assuming the kernel supposed such a thing), the randomness of ethN numbering for all non-motherboard NICs would be a disaster (although debatable if it would be any worse than it already is today). - Brian <[email protected]> Sent by: [email protected] 2010-11-16 08:42 AM To: <[email protected]> cc: [email protected] Subject: RE: Consistent Network Device Naming for LOMs coming... > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Zach White > Sent: Monday, November 15, 2010 4:58 PM [schnipp] > > Matt, I don't believe we are bikeshedding here. There are > legitimate concerns around calling network interfaces > anything that doesn't match /eth\d*/. There are even more > legitimate concerns around the collision with the "LOM" acronym. > > If you want to have consistent naming, please have the > scripts always name the first onboard interface "eth0" and > name the second "eth1." Picking any other name will lead to > confusion, extra work, and ticked off customers calling > support because their servers stopped working after an upgrade. I'm sorry I happen to agree with Zach here. In all scripts everywhere for as long as I have been using Linux servers and writing scripts, I have used ethX for network interfaces. I don't understand the need to name them lomX all of a sudden. Particularly, I don't see why we need to distinguish between on-board and add-in NICs in the first place, regardless of their name. I am grateful that I can change the naming scheme using udev, if needed, but I am very hesitant as too using lomX as a default in the near future, unless there is a very good reason that is carried in the community. And I am not aware of such a movement, please correct me if I am wrong. Chris. _______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
_______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
