public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ivan.khoronzhuk" <ivan.khoronzhuk@globallogic.com>
To: Jean Delvare <jdelvare@suse.de>,
	dmidecode-devel@nongnu.org,
	Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: 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: Wed, 04 Mar 2015 14:28:20 +0200	[thread overview]
Message-ID: <54F6FA64.7000609@globallogic.com> (raw)
In-Reply-To: <20150226104134.178e8c35@endymion.delvare>

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


  reply	other threads:[~2015-03-04 12:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 12:39 [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute 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 [this message]
2015-03-05  7:46           ` Jean Delvare
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=54F6FA64.7000609@globallogic.com \
    --to=ivan.khoronzhuk@globallogic.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dmidecode-devel@nongnu.org \
    --cc=grant.likely@linaro.org \
    --cc=ivan.khoronzhuk@linaro.org \
    --cc=jdelvare@suse.de \
    --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