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]
Message-ID: <54F6FA64.7000609@globallogic.com>
Date:	Wed, 04 Mar 2015 14:28:20 +0200
From:	"Ivan.khoronzhuk" <ivan.khoronzhuk@...ballogic.com>
To:	Jean Delvare <jdelvare@...e.de>, dmidecode-devel@...gnu.org,
	Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>
CC:	matt.fleming@...el.com, ard.biesheuvel@...aro.org,
	linux-kernel@...r.kernel.org, leif.lindholm@...aro.org,
	Mark Salter <msalter@...hat.com>, grant.likely@...aro.org
Subject: Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry
 point area raw attribute

Hi Jean.

On 02/26/2015 11:41 AM, Jean Delvare wrote:
> Replying to myself...
>
> On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
>> Please also note that the recently released version 3.0.0 of the SMBIOS
>> specification introduces a new entry point format, and the firmware is
>> allowed to implement both the old and the new format. It may be
>> desirable to expose both to user-space under different names.
> Having read the kernel code meanwhile, I see we will call either
> dmi_smbios3_present or dmi_present successfully, not both, so
> presenting both entry points to user-space would be non-trivial. So I'm
> fine with presenting only one entry point in sysfs for the time being.
> We can always revisit later if it turns out that dmidecode really needs
> both in some cases.
>

Why do you need two tables ? If kernel can parse the best one why
it should present the old one? The old is subset of new, so the new must
contain all required information, only format can be slightly different.
If dmidecode has problems in reading new version then dmidecode should
be modified, not kernel.

-- 
Regards,
Ivan Khoronzhuk

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ