Message-ID: <57B19185.40304@dell.com>
Date:	Mon, 15 Aug 2016 17:55:17 +0800
From:	Allen Hung <allen_hung@...l.com>
To:	"Limonciello, Mario" <Mario_Limonciello@...l.com>,
	Jean Delvare <jdelvare@...e.de>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
 strings to sysfs

On 08/03/2016 02:56 AM, Limonciello, Mario wrote:
>> -----Original Message-----
>> From: Jean Delvare [mailto:jdelvare@...e.de]
>> Sent: Tuesday, August 2, 2016 8:43 AM
>> To: Limonciello, Mario <Mario_Limonciello@...l.com>
>> Cc: Hung, Allen <Allen_Hung@...l.com>; linux-kernel@...r.kernel.org
>> Subject: Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
>> strings to sysfs
>>
>> Hi Mario, Allen,
>>
>> On Tue, 19 Jul 2016 14:47:57 +0000, Mario_Limonciello@...l.com wrote:
>>> Hi Jean,
>>>
>>> I worked with Allen on this concept, so I've got some comments below.
>>>
>>>> -----Original Message-----
>>>> From: Jean Delvare [mailto:jdelvare@...e.de]
>>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>>> To: Hung, Allen <Allen_Hung@...l.com>
>>>> Cc: Jean Delvare <jdelvare@...e.com>; linux-kernel@...r.kernel.org;
>>>> Limonciello, Mario <Mario_Limonciello@...l.com>
>>>> Subject: Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting
>> oem
>>>> strings to sysfs
>>>>
>>>> Hello Allen,
>>>>
>>>> On Thu, 14 Jul 2016 16:01:23 +0800, Allen Hung wrote:
>>>>> The oem strings in DMI system identification information of the BIOS
>> have
>>>>> been parsed and stored as dmi devices in dmi_scan.c but they are not
>>>>> exported to userspace via sysfs.
>>>>
>>>> They are intended for internal consumption by the kernel drivers.
>>>>
>>>>> The patch intends to export oem strings to sysfs device
>> /sys/class/dmi/id.
>>>>> As the number of oem strings are dynamic, a group "oem" is added to
>> the
>>>>> device and the strings will be added to the group as string1, string2, ...,
>>>>> and stringN.
>>>>
>>>> What is the use case? You can already get these strings easily using
>>>> dmidecode:
>>>>
>>>> # dmidecode -qt 11
>>>> OEM Strings
>>>> 	String 1: Dell System
>>>> 	String 2: 1[05A4]
>>>> 	String 3: 3[1.0]
>>>> 	String 4: 12[www.dell.com]
>>>> 	String 5: 14[1]
>>>> 	String 6: 15[3]
>>>> 	String 7:
>>>>
>>>> If needed, a dedicated option could be added to dmidecode to extract
>>>> specific OEM strings. Or existing option -s could be extended for that
>>>> purpose.
>>>
>>> The main purpose was to be able to parse these easily from userspace
>>> without needing dmidecode installed and handling its output
>>> (with tools such as grep, sed, and awk).
>>
>> As I just stated above: dmidecode could be extended to extract the oem
>> strings directly if there is a need for it.
>>
>>> For example in an initramfs, typically dmidecode isn't included, but there
>>> is value to being able to make decisions on things related to the values of
>>> those OEM strings.
>>
>> dmidecode is not included because nobody needs it. If you need it, you
>> can include it. 15 years ago, udev was not included in initramfs
>> either. But we still decided that this stuff should be done in
>> user-space and we wrote udev and added it to initramfs. It is in the
>> nature of initramfs to evolve with new needs, and to only include what
>> is needed on a given machine. mkinitrd/dracut checks the needs
>> dynamically. Why would it not work in your case?
>>
>> I would appreciate more details than "there is value..." I would like
>> to hear about an actual use case.
>>
>>> Instead this allows userspace to iterate the oem/ directory and directly
>>> look at the values of these strings.
>>
>> At the cost of code which will run at every boot, and kernel memory
>> which will be used forever, on all systems. This is why I am reluctant.
>> You don't put things in the kernel because this is the easiest way to
>> fulfill your immediate need. You put things in the kernel because you
>> absolutely have to, or at the very least because it is where it makes
>> the most sense. At this point I am not convinced this is the case here.
>> I see no reason why the same can't be implemented easily in user-space
>> (dmidecode and dracut.)
> 
> Thanks, when you put it this way your reluctance makes a lot more sense.
> I don't disagree that this could live in several different levels of the software
> stack.
> 
> The main reason that we want to have OEM tags exported is to access one
> particular OEM strings on Dell systems from userspace applications that should
> run on Dell systems (not just the initramfs).
> 
> There is string  that indicates that the system is a Dell System.  Normally this
> would be obvious from other SMBIOS strings (such as System Vendor)
> but Dell also does "OEM systems", which means that they might have 
> custom branding applied that has otherwise removed the Vendor and
> Product information.
> 
> Other strings indicate information that can be used to determine the
> original product model number and lots of other details.
> 
> On a system like this it's not possible to know it's a Dell system and what
> model it was before rebranding without looking at the OEM strings.
> 
> So by exporting the OEM strings from sysfs, it's possible to accurately 
> identify Dell systems regardless of whether they have custom branding
> applied without needing to rely on calling dmidecode.
> 
Hi Jean,

I revised the patch to turn the exporting of OEM strings into a sub-option under 
config DMIID and is disabled by default. We can turn on this kernel option only on
the systems Dell is going to ship, and it will not waste any memory on other systems
unless it is otherwise enabled. We don't disagree this is not a must in kernel but
the revised patch is meant to retain the value Mario wrote above, and to avoid the
waste on the systems those don't need it. Also, the file permissions are adjusted 
as 0400.
It was sent with the same title with the tag prefix "[PATCH v3 2/2] ..." in prefix.

Regards,
Allen

Powered by blists - more mailing lists