From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752799AbbCHSVh (ORCPT ); Sun, 8 Mar 2015 14:21:37 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35305 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751439AbbCHSVf (ORCPT ); Sun, 8 Mar 2015 14:21:35 -0400 Date: Sun, 8 Mar 2015 19:21:30 +0100 From: Jean Delvare To: Ard Biesheuvel Cc: "Ivan.khoronzhuk" , dmidecode-devel@nongnu.org, Ivan Khoronzhuk , Matt Fleming , "linux-kernel@vger.kernel.org" , Leif Lindholm , Mark Salter , Grant Likely Subject: Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute Message-ID: <20150308192130.2131534f@endymion.delvare> In-Reply-To: References: <1422448763-17583-1-git-send-email-ivan.khoronzhuk@linaro.org> <1422975508.18187.77.camel@deneb.redhat.com> <54D0EDE8.40207@linaro.org> <1424940642.25006.60.camel@chaos.site> <20150226104134.178e8c35@endymion.delvare> <54F6FA64.7000609@globallogic.com> <20150305084656.36d639a6@endymion.delvare> <54FB654C.2030601@globallogic.com> <20150308123125.7b324e47@endymion.delvare> <20150308181140.288dfa88@endymion.delvare> Organization: SUSE Linux X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 8 Mar 2015 18:38:57 +0100, Ard Biesheuvel wrote: > On 8 March 2015 at 18:11, Jean Delvare wrote: > > On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote: > >> And the 32-bit entry point could well be 3.0 anyway, if > >> it uses any of the new enum values for the data items that were > >> undefined before 3.0. > > > > This is true but irrelevant to the discussion. > > To clarify, the SMBIOS 3.0 spec explicitly allows the 32-bit entry > point to either point to the same table as the 64-bit entry point, or > point to a separate table, in which case the contents of the latter > should be a subset of the contents of the former. It doesn't specify > anything about the version number to be used in the 32-bit entry point > in case they point to separate tables. This means the presence of the > 32-bit entry point does not guarantee that the table contents are > compatible with the pre-3.0 tools. So perhaps it would make sense to > export the 32-bit entry point separately only if it points to a > different table, and has a different version number? The situation is exactly the same as with every new version of the SMBIOS specification: tools need to be updated to support the new enumerated values and the new fields, but are able to decode all the rest just fine. The only thing that would make it a different situation is if something in the 3.0 specification is incompatible with previous specifications. But I'd be very surprised if this is the case, as I am sure the DMTF people care about compatibility. And I can't see any practical case where the vendor would want to not implement version 3.0 in the _SM_-pointed table if they do so for the _SM3_-pointed table. That's more work for them and serves no purpose, as everything that could be encoded in old versions can also be encoded in newer versions. So, no, I still don't think there is any value in exposing two entry points in sysfs. -- Jean Delvare SUSE L3 Support