From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752854AbbCGUxl (ORCPT ); Sat, 7 Mar 2015 15:53:41 -0500 Received: from exprod5og112.obsmtp.com ([64.18.0.24]:40231 "EHLO exprod5og112.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752674AbbCGUxk (ORCPT ); Sat, 7 Mar 2015 15:53:40 -0500 Message-ID: <54FB654C.2030601@globallogic.com> Date: Sat, 07 Mar 2015 22:53:32 +0200 From: "Ivan.khoronzhuk" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jean Delvare CC: dmidecode-devel@nongnu.org, Ivan Khoronzhuk , matt.fleming@intel.com, ard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org, leif.lindholm@linaro.org, Mark Salter , grant.likely@linaro.org Subject: Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute 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> In-Reply-To: <20150305084656.36d639a6@endymion.delvare> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jean, On 03/05/2015 09:46 AM, Jean Delvare wrote: > 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. > Despite of timing is right. The specification doesn't oblige firmware to provide two entry points. An implementation may provide either the 32-bit entry point or the 64-bit entry point, or both. For compatibility with existing SMBIOS parsers, an implementation should provide the 32-bit entry point, but it's not required. Another case if specification requires to provide two entry points. Then you can be sure in backward compatibility. But at least for now you can't. It's obvious, if kernel found two entry points then it can create two sysfs attributes. But, what kernel should do in case if only one new entry point is present. Generate entry point of old version..., sorry but it's bad idea. At least because where guarantee that we have enough information for this. Only field we can bring thought entry point versions is magic string _SM*_, and based on it, if util don't support new version it can warn. It's used for differ versions and there is nothing we can do more. -- Regards, Ivan Khoronzhuk