Messages in this thread | | | Subject | Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs | From | Allen Hung <> | Date | Wed, 24 Aug 2016 16:05:43 +0800 |
| |
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
| |