> -----Original Message----- > From: Alex Chiang [mailto:achiang@xxxxxx] > Sent: Friday, February 26, 2010 3:10 AM > To: K, Narendra > Cc: netdev@xxxxxxxxxxxxxxx; linux-hotplug@xxxxxxxxxxxxxxx; linux- > pci@xxxxxxxxxxxxxxx; Domsch, Matt; Hargrave, Jordan; Shandilya, Sandeep > K; Rose, Charles; Iyer, Shyam > Subject: Re: [PATCH] Export smbios strings associated with onboard > devicesto sysfs > > * Narendra K <Narendra_K@xxxxxxxx>: > > > > * We have been having discussions in the netdev list about > > creating multiple names for the network interfaces to bring > > determinism into the way network interfaces are named in the > > OSes. In specific, "eth0 in the OS does not always map to the > > integrated NIC Gb1 as labelled on the chassis". > > Yes, I agree that this is a real problem that we do not handle > well today. > > > 1.Export smbios strings of onboard devices, to sysfs. For example - > > > > cat /sys/class/net/eth0/device/smbiosname > > Embedded NIC 2 > > > > cat /sys/bus/pci/devices/0000\:03\:00.0/smbiosname > > Embedded NIC 2 > > I agree with this concept, but I don't like the interface. > > The name "smbiosname" isn't the proper level of abstraction. We > don't want users to care what firmware standard is providing the > name (think smbios vs acpi vs open firmware...). > > We learned this lesson with exposing ACPI interfaces. Let's not > make the same mistake here. > > Something like "firmwarename", "fwname", "platformname" etc. is > generic, and then the interface will make sense for platforms > that do not implement SMBIOS. > > I don't particularly care which name you choose as long as it's > properly generic. > > As far as implementation goes, I've been thinking about this > problem for a while now, and I keep wanting to use the > pci_create_slot() API, but am still a little on the fence about > it. > > The pros: > - all you have to do is write a simple little driver that > can read SMBIOS to get PCI bus:devfn and the name, and > then you call pci_create_slot(). Then you get all sorts > of stuff for free, like sysfs exposure, proper > refcounting (important given that the PCI logical > hotplug interface (/sys/bus/pci/rescan and friends) can > be used to remove onboard devices), etc. > > - see drivers/acpi/pci_slot.c for an example of how to > detect slots and then register them. > > The cons: > - the user interface is /sys/bus/pci/slots/<name> > > I don't know if that is an appropriate interface, since > technically an onboard device isn't in a slot. But maybe > if you did something like: > > /sys/bus/pci/slots/onboard0 > /sys/bus/pci/slots/onboard1 > > that might make sense. > > Or... > /sys/bus/pci/onboard/<name> > > I read through the patch, but given that the implementation > strategy might change based on my comments, will hold off and see > how the conversation develops. Thanks. I will wait too, to see how the discussion develops on this method of implementation. 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
