From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759295AbbCDMfu (ORCPT ); Wed, 4 Mar 2015 07:35:50 -0500 Received: from exprod5og114.obsmtp.com ([64.18.0.28]:59592 "EHLO exprod5og114.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755700AbbCDMfs (ORCPT ); Wed, 4 Mar 2015 07:35:48 -0500 Message-ID: <54F6FA64.7000609@globallogic.com> Date: Wed, 04 Mar 2015 14:28:20 +0200 From: "Ivan.khoronzhuk" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jean Delvare , dmidecode-devel@nongnu.org, Ivan Khoronzhuk CC: 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> In-Reply-To: <20150226104134.178e8c35@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 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