On Thu, Sep 23, 2010 at 10:03:36PM +0530, Greg KH wrote: > On Thu, Sep 23, 2010 at 09:20:57PM +0530, Narendra_K@xxxxxxxx wrote: > > > Now trying to change the kernel namespace itself seems like a bad hack > > > around this fact. > > > > > > > The patch does not change the existing kernel name space. > > You are "reordering it", right? > > > It adheres to the existing ethN name space with IFNAMSIZ length > > requirements. The patch only makes sure that eth0 always corresponds > > to what is labeled as 'Gb1' on server chassis, on systems where SMBIOS > > type 41 record is available. And removes the need for any renames for > > the interfaces which have a firmware index assigned by system > > firmware, as the very first name assigned by the kernel will be as > > expected and deterministic. > > And on systems with buggy firmware, what is going to happen here? And > yes, there will be buggy BIOS tables, we can guarantee that, as this is > not something that Windows supports, right? > It took some time to find out the details asked above. Right, windows does not use SMBIOS type 41 record to derive names. But as a datapoint, windows also has the same problem. Yes, firmware and BIOS tables can be buggy. How about a command line parameter 'no_netfwindex', passing which firmware index will not be used to derive ethN names ? That would handle the scenario of buggy firmware and names will be derived in the now existing way. I will submit a patch shortly implementing this. -- With regards, Narendra K -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
