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

[Allen Hung]

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:jdelv...@suse.de]
>>> Sent: Tuesday, August 2, 2016 8:43 AM
>>> To: Limonciello, Mario <mario_limoncie...@dell.com>
>>> Cc: Hung, Allen <allen_h...@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 +, mario_limoncie...@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:jdelv...@suse.de]
>>>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>>>> To: Hung, Allen <allen_h...@dell.com>
>>>>> Cc: Jean Delvare <jdelv...@suse.com>; linux-kernel@vger.kernel.org;
>>>>> Limonciello, Mario <mario_limoncie...@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 se

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

[Allen Hung]

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:jdelv...@suse.de]
>>> Sent: Tuesday, August 2, 2016 8:43 AM
>>> To: Limonciello, Mario 
>>> Cc: Hung, Allen ; 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 +, mario_limoncie...@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:jdelv...@suse.de]
>>>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>>>> To: Hung, Allen 
>>>>> Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
>>>>> Limonciello, Mario 
>>>>> 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
&g

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

[Allen Hung]

On 08/03/2016 02:56 AM, Limonciello, Mario wrote:
>> -Original Message-
>> From: Jean Delvare [mailto:jdelv...@suse.de]
>> Sent: Tuesday, August 2, 2016 8:43 AM
>> To: Limonciello, Mario <mario_limoncie...@dell.com>
>> Cc: Hung, Allen <allen_h...@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 +, mario_limoncie...@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:jdelv...@suse.de]
>>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>>> To: Hung, Allen <allen_h...@dell.com>
>>>> Cc: Jean Delvare <jdelv...@suse.com>; linux-kernel@vger.kernel.org;
>>>> Limonciello, Mario <mario_limoncie...@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 t

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

[Allen Hung]

On 08/03/2016 02:56 AM, Limonciello, Mario wrote:
>> -Original Message-
>> From: Jean Delvare [mailto:jdelv...@suse.de]
>> Sent: Tuesday, August 2, 2016 8:43 AM
>> To: Limonciello, Mario 
>> Cc: Hung, Allen ; 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 +, mario_limoncie...@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:jdelv...@suse.de]
>>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>>> To: Hung, Allen 
>>>> Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
>>>> Limonciello, Mario 
>>>> 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 sys

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

[Mario_Limonciello]

> -Original Message-
> From: Jean Delvare [mailto:jdelv...@suse.de]
> Sent: Tuesday, August 2, 2016 8:43 AM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: Hung, Allen <allen_h...@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 +, mario_limoncie...@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:jdelv...@suse.de]
> > > Sent: Tuesday, July 19, 2016 4:03 AM
> > > To: Hung, Allen <allen_h...@dell.com>
> > > Cc: Jean Delvare <jdelv...@suse.com>; linux-kernel@vger.kernel.org;
> > > Limonciello, Mario <mario_limoncie...@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.

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

[Mario_Limonciello]

> -Original Message-
> From: Jean Delvare [mailto:jdelv...@suse.de]
> Sent: Tuesday, August 2, 2016 8:43 AM
> To: Limonciello, Mario 
> Cc: Hung, Allen ; 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 +, mario_limoncie...@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:jdelv...@suse.de]
> > > Sent: Tuesday, July 19, 2016 4:03 AM
> > > To: Hung, Allen 
> > > Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
> > > Limonciello, Mario 
> > > 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.

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

[Jean Delvare]

Hi Mario, Allen,

On Tue, 19 Jul 2016 14:47:57 +, mario_limoncie...@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:jdelv...@suse.de]
> > Sent: Tuesday, July 19, 2016 4:03 AM
> > To: Hung, Allen <allen_h...@dell.com>
> > Cc: Jean Delvare <jdelv...@suse.com>; linux-kernel@vger.kernel.org;
> > Limonciello, Mario <mario_limoncie...@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.)

> > Also your code doesn't even build. I won't review this patch until I
> > know why it is needed, and it builds (without warning.)
> 
> Allen had a mistake in that submission when he was refactoring it prior to 
> LKML submission.  
> He resubmitted it the next day fixing that mistake:
> https://patchwork.kernel.org/patch/9231473/

Sorry, my bad. The updated patch was already available when I
complained, just had not crawled far enough in my mailbox at the time I
replied.

-- 
Jean Delvare
SUSE L3 Support

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

[Jean Delvare]

Hi Mario, Allen,

On Tue, 19 Jul 2016 14:47:57 +, mario_limoncie...@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:jdelv...@suse.de]
> > Sent: Tuesday, July 19, 2016 4:03 AM
> > To: Hung, Allen 
> > Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
> > Limonciello, Mario 
> > 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.)

> > Also your code doesn't even build. I won't review this patch until I
> > know why it is needed, and it builds (without warning.)
> 
> Allen had a mistake in that submission when he was refactoring it prior to 
> LKML submission.  
> He resubmitted it the next day fixing that mistake:
> https://patchwork.kernel.org/patch/9231473/

Sorry, my bad. The updated patch was already available when I
complained, just had not crawled far enough in my mailbox at the time I
replied.

-- 
Jean Delvare
SUSE L3 Support

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

[Allen Hung]

On 07/27/2016 05:03 AM, Limonciello, Mario wrote:
>> -Original Message-
>> From: Limonciello, Mario
>> Sent: Tuesday, July 19, 2016 9:48 AM
>> To: 'Jean Delvare' <jdelv...@suse.de>; Hung, Allen <allen_h...@dell.com>
>> Cc: Jean Delvare <jdelv...@suse.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 Jean,
>>
>> I worked with Allen on this concept, so I've got some comments below.
>>
>>> -Original Message-
>>> From: Jean Delvare [mailto:jdelv...@suse.de]
>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>> To: Hung, Allen <allen_h...@dell.com>
>>> Cc: Jean Delvare <jdelv...@suse.com>; linux-kernel@vger.kernel.org;
>>> Limonciello, Mario <mario_limoncie...@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).
>>
>> 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.
>>
>> Instead this allows userspace to iterate the oem/ directory and directly
>> look at the values of these strings.
>>
>>>
>>> Also your code doesn't even build. I won't review this patch until I
>>> know why it is needed, and it builds (without warning.)
>>>
>>
>> Allen had a mistake in that submission when he was refactoring it prior to
>> LKML submission.
>> He resubmitted it the next day fixing that mistake:
>> https://patchwork.kernel.org/patch/9231473/
>>
>>> One comment below though:
>>>
>>>>
>>>> Signed-off-by: Allen Hung <allen_h...@dell.com>
>>>> ---
>>>>  drivers/firmware/dmi-id.c | 108
>>> ++
>>>>  1 file changed, 108 insertions(+)
>>>>
>>>> diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
>>>> index 44c0139..f284a07 100644
>>>> --- a/drivers/firmware/dmi-id.c
>>>> +++ b/drivers/firmware/dmi-id.c
>>>> (...)
>>>> +static int __init dmi_id_init_oem_attr_group(void)
>>>> +{
>>>> +  int i, ret;
>>>> +  const struct dmi_device *dev;
>>>> +  struct dmi_oem_attribute *oa, *tmp;
>>>> +  struct device_attribute dev_attr_tmpl =
>>>> +  __ATTR(, 0444, sys_dmi_oem_show, NULL);
>>>
>>> I'd be very careful about permissions. OEM strings could contain pretty
>>> much everything, including serial numbers or passwords. Making these
>>> files world-readable doesn't strike me as the best of the ideas.
>>>
>>
>> At least on Dell systems, the values in these strings are OK to be world
>> readable, but I understand this concern and agree that Allen should adjust
>> these permissions in the next version if you agree with the concept of this
>> patch.
>>
>> Thanks,
> 
> Hi jean,
> 
> Did you have any comments about Allen's updated patch or my above
> comments?
> 
> If necessary, Allen can resend with the fix to OEM strings permissions
> and we can discuss further then.
> 
> Thanks,
> 
Hi Jean,
I didn't send my earlier fix beginning with "PATCH v2" so it may bring up some 
confusing. I am sorry about it.
I have just resent it with prefix "PATCH v2" and the OEM string permissions 
still remain what they were in my first submission.
Hope we can get the feedbacks from you.

Regards,
Allen

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

[Allen Hung]

On 07/27/2016 05:03 AM, Limonciello, Mario wrote:
>> -Original Message-
>> From: Limonciello, Mario
>> Sent: Tuesday, July 19, 2016 9:48 AM
>> To: 'Jean Delvare' ; Hung, Allen 
>> Cc: Jean Delvare ; linux-kernel@vger.kernel.org
>> Subject: RE: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
>> strings to sysfs
>>
>> Hi Jean,
>>
>> I worked with Allen on this concept, so I've got some comments below.
>>
>>> -Original Message-
>>> From: Jean Delvare [mailto:jdelv...@suse.de]
>>> Sent: Tuesday, July 19, 2016 4:03 AM
>>> To: Hung, Allen 
>>> Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
>>> Limonciello, Mario 
>>> 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).
>>
>> 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.
>>
>> Instead this allows userspace to iterate the oem/ directory and directly
>> look at the values of these strings.
>>
>>>
>>> Also your code doesn't even build. I won't review this patch until I
>>> know why it is needed, and it builds (without warning.)
>>>
>>
>> Allen had a mistake in that submission when he was refactoring it prior to
>> LKML submission.
>> He resubmitted it the next day fixing that mistake:
>> https://patchwork.kernel.org/patch/9231473/
>>
>>> One comment below though:
>>>
>>>>
>>>> Signed-off-by: Allen Hung 
>>>> ---
>>>>  drivers/firmware/dmi-id.c | 108
>>> ++
>>>>  1 file changed, 108 insertions(+)
>>>>
>>>> diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
>>>> index 44c0139..f284a07 100644
>>>> --- a/drivers/firmware/dmi-id.c
>>>> +++ b/drivers/firmware/dmi-id.c
>>>> (...)
>>>> +static int __init dmi_id_init_oem_attr_group(void)
>>>> +{
>>>> +  int i, ret;
>>>> +  const struct dmi_device *dev;
>>>> +  struct dmi_oem_attribute *oa, *tmp;
>>>> +  struct device_attribute dev_attr_tmpl =
>>>> +  __ATTR(, 0444, sys_dmi_oem_show, NULL);
>>>
>>> I'd be very careful about permissions. OEM strings could contain pretty
>>> much everything, including serial numbers or passwords. Making these
>>> files world-readable doesn't strike me as the best of the ideas.
>>>
>>
>> At least on Dell systems, the values in these strings are OK to be world
>> readable, but I understand this concern and agree that Allen should adjust
>> these permissions in the next version if you agree with the concept of this
>> patch.
>>
>> Thanks,
> 
> Hi jean,
> 
> Did you have any comments about Allen's updated patch or my above
> comments?
> 
> If necessary, Allen can resend with the fix to OEM strings permissions
> and we can discuss further then.
> 
> Thanks,
> 
Hi Jean,
I didn't send my earlier fix beginning with "PATCH v2" so it may bring up some 
confusing. I am sorry about it.
I have just resent it with prefix "PATCH v2" and the OEM string permissions 
still remain what they were in my first submission.
Hope we can get the feedbacks from you.

Regards,
Allen

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

[Mario_Limonciello]

> -Original Message-
> From: Limonciello, Mario
> Sent: Tuesday, July 19, 2016 9:48 AM
> To: 'Jean Delvare' <jdelv...@suse.de>; Hung, Allen <allen_h...@dell.com>
> Cc: Jean Delvare <jdelv...@suse.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 Jean,
> 
> I worked with Allen on this concept, so I've got some comments below.
> 
> > -Original Message-
> > From: Jean Delvare [mailto:jdelv...@suse.de]
> > Sent: Tuesday, July 19, 2016 4:03 AM
> > To: Hung, Allen <allen_h...@dell.com>
> > Cc: Jean Delvare <jdelv...@suse.com>; linux-kernel@vger.kernel.org;
> > Limonciello, Mario <mario_limoncie...@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).
> 
> 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.
> 
> Instead this allows userspace to iterate the oem/ directory and directly
> look at the values of these strings.
> 
> >
> > Also your code doesn't even build. I won't review this patch until I
> > know why it is needed, and it builds (without warning.)
> >
> 
> Allen had a mistake in that submission when he was refactoring it prior to
> LKML submission.
> He resubmitted it the next day fixing that mistake:
> https://patchwork.kernel.org/patch/9231473/
> 
> > One comment below though:
> >
> > >
> > > Signed-off-by: Allen Hung <allen_h...@dell.com>
> > > ---
> > >  drivers/firmware/dmi-id.c | 108
> > ++
> > >  1 file changed, 108 insertions(+)
> > >
> > > diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> > > index 44c0139..f284a07 100644
> > > --- a/drivers/firmware/dmi-id.c
> > > +++ b/drivers/firmware/dmi-id.c
> > > (...)
> > > +static int __init dmi_id_init_oem_attr_group(void)
> > > +{
> > > + int i, ret;
> > > + const struct dmi_device *dev;
> > > + struct dmi_oem_attribute *oa, *tmp;
> > > + struct device_attribute dev_attr_tmpl =
> > > + __ATTR(, 0444, sys_dmi_oem_show, NULL);
> >
> > I'd be very careful about permissions. OEM strings could contain pretty
> > much everything, including serial numbers or passwords. Making these
> > files world-readable doesn't strike me as the best of the ideas.
> >
> 
> At least on Dell systems, the values in these strings are OK to be world
> readable, but I understand this concern and agree that Allen should adjust
> these permissions in the next version if you agree with the concept of this
> patch.
> 
> Thanks,

Hi jean,

Did you have any comments about Allen's updated patch or my above
comments?

If necessary, Allen can resend with the fix to OEM strings permissions
and we can discuss further then.

Thanks,

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

[Mario_Limonciello]

> -Original Message-
> From: Limonciello, Mario
> Sent: Tuesday, July 19, 2016 9:48 AM
> To: 'Jean Delvare' ; Hung, Allen 
> Cc: Jean Delvare ; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
> strings to sysfs
> 
> Hi Jean,
> 
> I worked with Allen on this concept, so I've got some comments below.
> 
> > -Original Message-
> > From: Jean Delvare [mailto:jdelv...@suse.de]
> > Sent: Tuesday, July 19, 2016 4:03 AM
> > To: Hung, Allen 
> > Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
> > Limonciello, Mario 
> > 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).
> 
> 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.
> 
> Instead this allows userspace to iterate the oem/ directory and directly
> look at the values of these strings.
> 
> >
> > Also your code doesn't even build. I won't review this patch until I
> > know why it is needed, and it builds (without warning.)
> >
> 
> Allen had a mistake in that submission when he was refactoring it prior to
> LKML submission.
> He resubmitted it the next day fixing that mistake:
> https://patchwork.kernel.org/patch/9231473/
> 
> > One comment below though:
> >
> > >
> > > Signed-off-by: Allen Hung 
> > > ---
> > >  drivers/firmware/dmi-id.c | 108
> > ++
> > >  1 file changed, 108 insertions(+)
> > >
> > > diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> > > index 44c0139..f284a07 100644
> > > --- a/drivers/firmware/dmi-id.c
> > > +++ b/drivers/firmware/dmi-id.c
> > > (...)
> > > +static int __init dmi_id_init_oem_attr_group(void)
> > > +{
> > > + int i, ret;
> > > + const struct dmi_device *dev;
> > > + struct dmi_oem_attribute *oa, *tmp;
> > > + struct device_attribute dev_attr_tmpl =
> > > + __ATTR(, 0444, sys_dmi_oem_show, NULL);
> >
> > I'd be very careful about permissions. OEM strings could contain pretty
> > much everything, including serial numbers or passwords. Making these
> > files world-readable doesn't strike me as the best of the ideas.
> >
> 
> At least on Dell systems, the values in these strings are OK to be world
> readable, but I understand this concern and agree that Allen should adjust
> these permissions in the next version if you agree with the concept of this
> patch.
> 
> Thanks,

Hi jean,

Did you have any comments about Allen's updated patch or my above
comments?

If necessary, Allen can resend with the fix to OEM strings permissions
and we can discuss further then.

Thanks,

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

[Mario_Limonciello]

Hi Jean,

I worked with Allen on this concept, so I've got some comments below.

> -Original Message-
> From: Jean Delvare [mailto:jdelv...@suse.de]
> Sent: Tuesday, July 19, 2016 4:03 AM
> To: Hung, Allen <allen_h...@dell.com>
> Cc: Jean Delvare <jdelv...@suse.com>; linux-kernel@vger.kernel.org;
> Limonciello, Mario <mario_limoncie...@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).

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.

Instead this allows userspace to iterate the oem/ directory and directly
look at the values of these strings.

> 
> Also your code doesn't even build. I won't review this patch until I
> know why it is needed, and it builds (without warning.)
> 

Allen had a mistake in that submission when he was refactoring it prior to 
LKML submission.  
He resubmitted it the next day fixing that mistake:
https://patchwork.kernel.org/patch/9231473/

> One comment below though:
> 
> >
> > Signed-off-by: Allen Hung <allen_h...@dell.com>
> > ---
> >  drivers/firmware/dmi-id.c | 108
> ++
> >  1 file changed, 108 insertions(+)
> >
> > diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> > index 44c0139..f284a07 100644
> > --- a/drivers/firmware/dmi-id.c
> > +++ b/drivers/firmware/dmi-id.c
> > (...)
> > +static int __init dmi_id_init_oem_attr_group(void)
> > +{
> > +   int i, ret;
> > +   const struct dmi_device *dev;
> > +   struct dmi_oem_attribute *oa, *tmp;
> > +   struct device_attribute dev_attr_tmpl =
> > +   __ATTR(, 0444, sys_dmi_oem_show, NULL);
> 
> I'd be very careful about permissions. OEM strings could contain pretty
> much everything, including serial numbers or passwords. Making these
> files world-readable doesn't strike me as the best of the ideas.
> 

At least on Dell systems, the values in these strings are OK to be world
readable, but I understand this concern and agree that Allen should adjust
these permissions in the next version if you agree with the concept of this
patch.

Thanks,

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

[Mario_Limonciello]

Hi Jean,

I worked with Allen on this concept, so I've got some comments below.

> -Original Message-
> From: Jean Delvare [mailto:jdelv...@suse.de]
> Sent: Tuesday, July 19, 2016 4:03 AM
> To: Hung, Allen 
> Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
> Limonciello, Mario 
> 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).

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.

Instead this allows userspace to iterate the oem/ directory and directly
look at the values of these strings.

> 
> Also your code doesn't even build. I won't review this patch until I
> know why it is needed, and it builds (without warning.)
> 

Allen had a mistake in that submission when he was refactoring it prior to 
LKML submission.  
He resubmitted it the next day fixing that mistake:
https://patchwork.kernel.org/patch/9231473/

> One comment below though:
> 
> >
> > Signed-off-by: Allen Hung 
> > ---
> >  drivers/firmware/dmi-id.c | 108
> ++
> >  1 file changed, 108 insertions(+)
> >
> > diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> > index 44c0139..f284a07 100644
> > --- a/drivers/firmware/dmi-id.c
> > +++ b/drivers/firmware/dmi-id.c
> > (...)
> > +static int __init dmi_id_init_oem_attr_group(void)
> > +{
> > +   int i, ret;
> > +   const struct dmi_device *dev;
> > +   struct dmi_oem_attribute *oa, *tmp;
> > +   struct device_attribute dev_attr_tmpl =
> > +   __ATTR(, 0444, sys_dmi_oem_show, NULL);
> 
> I'd be very careful about permissions. OEM strings could contain pretty
> much everything, including serial numbers or passwords. Making these
> files world-readable doesn't strike me as the best of the ideas.
> 

At least on Dell systems, the values in these strings are OK to be world
readable, but I understand this concern and agree that Allen should adjust
these permissions in the next version if you agree with the concept of this
patch.

Thanks,

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

[Jean Delvare]

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.

Also your code doesn't even build. I won't review this patch until I
know why it is needed, and it builds (without warning.)

One comment below though:

> 
> Signed-off-by: Allen Hung 
> ---
>  drivers/firmware/dmi-id.c | 108 
> ++
>  1 file changed, 108 insertions(+)
> 
> diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> index 44c0139..f284a07 100644
> --- a/drivers/firmware/dmi-id.c
> +++ b/drivers/firmware/dmi-id.c
> (...)
> +static int __init dmi_id_init_oem_attr_group(void)
> +{
> + int i, ret;
> + const struct dmi_device *dev;
> + struct dmi_oem_attribute *oa, *tmp;
> + struct device_attribute dev_attr_tmpl =
> + __ATTR(, 0444, sys_dmi_oem_show, NULL);

I'd be very careful about permissions. OEM strings could contain pretty
much everything, including serial numbers or passwords. Making these
files world-readable doesn't strike me as the best of the ideas.

-- 
Jean Delvare
SUSE L3 Support

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

[Jean Delvare]

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.

Also your code doesn't even build. I won't review this patch until I
know why it is needed, and it builds (without warning.)

One comment below though:

> 
> Signed-off-by: Allen Hung 
> ---
>  drivers/firmware/dmi-id.c | 108 
> ++
>  1 file changed, 108 insertions(+)
> 
> diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
> index 44c0139..f284a07 100644
> --- a/drivers/firmware/dmi-id.c
> +++ b/drivers/firmware/dmi-id.c
> (...)
> +static int __init dmi_id_init_oem_attr_group(void)
> +{
> + int i, ret;
> + const struct dmi_device *dev;
> + struct dmi_oem_attribute *oa, *tmp;
> + struct device_attribute dev_attr_tmpl =
> + __ATTR(, 0444, sys_dmi_oem_show, NULL);

I'd be very careful about permissions. OEM strings could contain pretty
much everything, including serial numbers or passwords. Making these
files world-readable doesn't strike me as the best of the ideas.

-- 
Jean Delvare
SUSE L3 Support

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

[kbuild test robot]

Hi,

[auto build test ERROR on v4.7-rc7]
[also build test ERROR on next-20160713]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Allen-Hung/dmi-id-export-oem-strings-to-sysfs/20160714-161631
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/firmware/dmi-id.c: In function 'dmi_id_init_oem_attr_group':
>> drivers/firmware/dmi-id.c:107:28: error: 'dmi_dev' undeclared (first use in 
>> this function)
 ret = sysfs_create_group(_dev->kobj, _oem_attr_group);
   ^~~
   drivers/firmware/dmi-id.c:107:28: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/dmi_dev +107 drivers/firmware/dmi-id.c

   101  int i, ret;
   102  const struct dmi_device *dev;
   103  struct dmi_oem_attribute *oa, *tmp;
   104  struct device_attribute dev_attr_tmpl =
   105  __ATTR(, 0444, sys_dmi_oem_show, NULL);
   106  
 > 107  ret = sysfs_create_group(_dev->kobj, _oem_attr_group);
   108  if (ret)
   109  return ret;
   110  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

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

[kbuild test robot]

Hi,

[auto build test ERROR on v4.7-rc7]
[also build test ERROR on next-20160713]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Allen-Hung/dmi-id-export-oem-strings-to-sysfs/20160714-161631
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/firmware/dmi-id.c: In function 'dmi_id_init_oem_attr_group':
>> drivers/firmware/dmi-id.c:107:28: error: 'dmi_dev' undeclared (first use in 
>> this function)
 ret = sysfs_create_group(_dev->kobj, _oem_attr_group);
   ^~~
   drivers/firmware/dmi-id.c:107:28: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/dmi_dev +107 drivers/firmware/dmi-id.c

   101  int i, ret;
   102  const struct dmi_device *dev;
   103  struct dmi_oem_attribute *oa, *tmp;
   104  struct device_attribute dev_attr_tmpl =
   105  __ATTR(, 0444, sys_dmi_oem_show, NULL);
   106  
 > 107  ret = sysfs_create_group(_dev->kobj, _oem_attr_group);
   108  if (ret)
   109  return ret;
   110  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data