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 +0000, Mario_Limonciello@xxxxxxxx wrote:
> Hi Jean,
> 
> I worked with Allen on this concept, so I've got some comments below.
> 
> > -----Original Message-----
> > From: Jean Delvare [mailto:jdelvare@xxxxxxx]
> > Sent: Tuesday, July 19, 2016 4:03 AM
> > To: Hung, Allen <Allen_Hung@xxxxxxxx>
> > Cc: Jean Delvare <jdelvare@xxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> > Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> > 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