On Tue, Nov 16, 2010 at 07:40:58PM +0530, [email protected] wrote: > 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.
The N was not arbitrary and was derived from a definitive knowledge of how many 'onboard' network interfaces exist in the system. It is available to the OS via SMBIOS type 41 record. So there was not any discontinuity b/w onboard ethN and add-in ethNs. With regards, Narendra K > > 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). > _______________________________________________ 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
