Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs

[Allen Hung <allen_hung@Dell.com>]

On 08/15/2016 05:55 PM, Allen Hung wrote:
> On 08/03/2016 02:56 AM, Limonciello, Mario wrote:
>>> -----Original Message-----
>>> From: Jean Delvare [mailto:jdelvare@suse.de]
>>> Sent: Tuesday, August 2, 2016 8:43 AM
>>> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
>>> Cc: Hung, Allen <Allen_Hung@Dell.com>; linux-kernel@vger.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@Dell.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@suse.de]
>>>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>>>> To: Hung, Allen <Allen_Hung@Dell.com>
>>>>> Cc: Jean Delvare <jdelvare@suse.com>; linux-kernel@vger.kernel.org;
>>>>> Limonciello, Mario <Mario_Limonciello@Dell.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
> 
Hi Jean,

Please let us know if you have feedbacks on my patch "[PATCH v3 2/2] dmi-id: add 
dmi/id/oem group for exporting oem strings to sysfs" sent on August 15.

Regards,
Allen