On Fri, Oct 30, 2009 at 10:23:57PM +0530, Narendra_K@xxxxxxxx wrote: > > >> >There are two issues, which really seem distinct to me. > >> > > >> >Users expect eth0 to map to first-onboard-nic. That's an installer > >> >issue (since the BIOS can already export this info) and I > >agree that > >> >if we want to "fix" that, we should fix it there. > >> > > >> > >> I agree that installers have to be fixed in the sense that > >they can be > >> told to find the right interface. But, they expect determinism and > >> depend on "eth0 to map to first-onboard-nic". Installer is > >one of the > >> applications that is affected by this and needs user > >intervention, if > >> it is not told about the right interface. I discussed > >installer as it > >> is so much part of a user experience. > > > >Right, but couldn't the installer do the work of scanning the > >SMBIOS to figure out which nics are onboard, and reorder the > >'eth*' names such that these are first? This state could then > >be written out as udev rules so that they persist across reboots. > > > > I suppose, with udev loading modules, the rules generated at runtime > could run into the problem of duplicate names, if names are reordered in > the kernel namespace. (I.e the eth* namespace). Hence idea of an > alternate namespace. I don't see a risk of duplicate names - after all drivers are loaded, the installer can take the names enumerated by the kernel, figure out what it thinks a preferrable order is (i.e. by querying SMBIOS), then change the kernel names/mac mapping appropriately. Where can a duplicate name become an issue using this method? -- dann frazier -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
