From: Jean Delvare <jdelvare@suse.de>
To: "Ivan.khoronzhuk" <ivan.khoronzhuk@globallogic.com>
Cc: dmidecode-devel@nongnu.org,
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>,
matt.fleming@intel.com, ard.biesheuvel@linaro.org,
linux-kernel@vger.kernel.org, leif.lindholm@linaro.org,
Mark Salter <msalter@redhat.com>,
grant.likely@linaro.org
Subject: Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute
Date: Thu, 5 Mar 2015 08:46:56 +0100 [thread overview]
Message-ID: <20150305084656.36d639a6@endymion.delvare> (raw)
In-Reply-To: <54F6FA64.7000609@globallogic.com>
Hi Ivan,
On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:
> On 02/26/2015 11:41 AM, Jean Delvare wrote:
> > 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.
It's not just two tables (I don't expect a lot of BIOSes to provide two
tables in practice, and they would have essentially the same format
anyway) but more importantly two entry points. The _SM3_ entry point is
brand new and most applications (including dmidecode) don't support it
yet. It doesn't matter if the kernel itself can parse it, as it passes
the raw entry point to applications anyway.
It happens that we are introducing this new sysfs raw interface at the
same time _SM3_ is being introduced, so we do not have to care about
backwards compatibility. Both the kernel and dmidecode will need to be
updated to support the new interface, so we can keep things simple and
let the kernel expose only the best entry point.
If the sysfs raw interface was already present at the time _SM3_
support was being added, then we would have had to present both entry
points for backwards compatibility. And if some _SM4_ entry point is
ever added in the future with a new format, we will have to export it
as a new sysfs attribute so as to not break compatibility.
As a summary, I agree that a single entry point file is OK for now, but
only because we are lucky that the timing is right.
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2015-03-05 7:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 12:39 Ivan Khoronzhuk
2015-01-28 15:56 ` Ivan Khoronzhuk
2015-02-03 10:49 ` Matt Fleming
2015-02-03 14:47 ` Ivan Khoronzhuk
2015-02-03 14:58 ` Mark Salter
2015-02-03 15:48 ` Ivan Khoronzhuk
2015-02-26 8:50 ` [dmidecode] " Jean Delvare
2015-02-26 9:41 ` Jean Delvare
2015-03-04 12:28 ` Ivan.khoronzhuk
2015-03-05 7:46 ` Jean Delvare [this message]
2015-03-07 20:53 ` Ivan.khoronzhuk
2015-03-08 11:31 ` Jean Delvare
2015-03-08 13:53 ` Ard Biesheuvel
2015-03-08 17:11 ` Jean Delvare
2015-03-08 17:38 ` Ard Biesheuvel
2015-03-08 18:21 ` Jean Delvare
2015-03-04 12:28 ` Ivan.khoronzhuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150305084656.36d639a6@endymion.delvare \
--to=jdelvare@suse.de \
--cc=ard.biesheuvel@linaro.org \
--cc=dmidecode-devel@nongnu.org \
--cc=grant.likely@linaro.org \
--cc=ivan.khoronzhuk@globallogic.com \
--cc=ivan.khoronzhuk@linaro.org \
--cc=leif.lindholm@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=msalter@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®