netdev - Re: [PATCH] Export smbios strings associated with onboard devices to sysfs

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Feb 2010 14:40:20 -0700
From:	Alex Chiang <achiang@...com>
To:	Narendra K <Narendra_K@...l.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 devices
	to 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,
/ac
--
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