| 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: <20101223143203.GA12256@auslistsprd01.us.dell.com> Date: Thu, 23 Dec 2010 08:32:03 -0600 From: Matt Domsch <Matt_Domsch@...l.com> To: Narendra_K@...l.com Cc: linux-pci@...r.kernel.org, linux-hotplug@...r.kernel.org, netdev@...r.kernel.org, Jordan_Hargrave@...l.com, Charles_Rose@...l.com, Vijay_Nijhawan@...l.com Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@...l.com wrote: > Hello, > > This patch exports ACPI _DSM provided firmware instance number and > string name to sysfs. > > Please review - There are now two different meanings for the 'index' file: 1) SMBIOS-provided "type instance" value, which I've only seen in range [1..N] for N devices, monotonically stepwise increasing. 2) ACPI-provided "index" value, which per spec only needs to be a "sort key", not starting at 0 or 1, and while monotonically increasing, not necessarily stepwise. It's perfectly valid for the values to be (12, 16, 27, 29) if that's convenient for BIOS to generate. Therefore, a consumer of this value (such as biosdevname) must know which of the two it's dealing with, and either accept the value as-is, or sort the value list. While I suppose it could sort the value list in either case, I'd prefer the ACPI value to be exposed in its own file, perhaps 'acpi_index', to make this explicit rather than implicit. 'label' is fine for either case, with ACPI taking priority over SMBIOS if both happen to be present. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- 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