lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <EDA0A4495861324DA2618B4C45DCB3EE6122A3@blrx3m08.blr.amer.dell.com> Date: Tue, 2 Mar 2010 23:12:07 +0530 From: <Narendra_K@...l.com> To: <achiang@...com> Cc: <netdev@...r.kernel.org>, <linux-hotplug@...r.kernel.org>, <linux-pci@...r.kernel.org>, <Matt_Domsch@...l.com>, <Jordan_Hargrave@...l.com>, <Sandeep_K_Shandilya@...l.com>, <Charles_Rose@...l.com>, <Shyam_Iyer@...l.com> Subject: RE: [PATCH] Export smbios strings associated with onboard devicesto sysfs > -----Original Message----- > From: Alex Chiang [mailto:achiang@...com] > Sent: Friday, February 26, 2010 3:10 AM > To: K, Narendra > Cc: netdev@...r.kernel.org; linux-hotplug@...r.kernel.org; linux- > pci@...r.kernel.org; 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@...l.com>: > > > > * 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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists