Re: [PATCH v2] Add a module for retrieving SMBIOS information
On Mon, Mar 16, 2015 at 2:26 PM, Rajat Jain rajatj...@juniper.net wrote: Hello, Just wanted to check on the status of this patch. Has it been accepted / merged? No, sorry, I lost track of it. There are still a few points I need to change from Andrei's review before sending a new revision. David ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
RE: [PATCH v2] Add a module for retrieving SMBIOS information
Hello,
Just wanted to check on the status of this patch. Has it been accepted / merged?
Thanks,
Rajat
-Original Message-
From: David Michael [mailto:fedora@gmail.com]
Sent: Sunday, February 15, 2015 7:11 PM
To: Andrei Borzenkov
Cc: The development of GNU GRUB; Prarit Bhargava; Leif Lindholm; Rajat
Jain; Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman
Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information
On Wed, Feb 11, 2015 at 6:34 AM, Andrei Borzenkov arvidj...@gmail.com
wrote:
В Sun, 08 Feb 2015 13:54:46 -0500
David Michael fedora@gmail.com пишет:
+@item
+Specifying @option{-t} will only print entries with a matching
+@var{type}. The type can be any value from 0 to 255. Specify a
+value outside this range to match entries with any type. The default is -
1.
I think out of range value should result in error.
Okay, but I think the user should still be able to specify a value that can
remove a previously specified type. Maybe a separate long option --no-
type or a magic value like -t any?
+ /* Write the entry's mandatory four header bytes. */ length =
+ ptr[1]; grub_printf (Entry: Type=0x%02x Length=0x%02x
+ Handle=0x%04x\n,
+ ptr[0], length, *(1 + (grub_uint16_t *)ptr));
Could you reverse the order in 1 + (grub_uint16_t *)ptr and in other
places too?
I'll replace all these pointer casts+dereferences with functions that avoid
alignment issues.
+ /* Dump of the formatted area (including the header) in hex. */
+ grub_printf ( Hex Dump: ); while (length-- 0)
+grub_printf (%02x, *ptr++);
+ grub_printf (\n);
+
+ /* Print each string found in the appended string list. */ while
+ (ptr[0] != 0 || ptr[1] != 0)
I wonder do we have any ad hoc way to limit it? It looks like Linux
kernel does more sanity checks and does not blindly trust data.
The entry point structure has a two-byte field for total SMBIOS table length,
so that can put an upper limit on the string sets.
Thanks for the detailed review. I hope to be able to be able to send a new
revision later in the week.
Side note: A new major version of the SMBIOS specification was posted last
week which includes 64-bit addresses and such. I'm not planning to try to
add this at the moment, unless anyone has a need for it.
Thanks.
David
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Add a module for retrieving SMBIOS information
On Wed, Feb 11, 2015 at 6:34 AM, Andrei Borzenkov arvidj...@gmail.com wrote:
В Sun, 08 Feb 2015 13:54:46 -0500
David Michael fedora@gmail.com пишет:
+@item
+Specifying @option{-t} will only print entries with a matching @var{type}.
The
+type can be any value from 0 to 255. Specify a value outside this range to
+match entries with any type. The default is -1.
I think out of range value should result in error.
Okay, but I think the user should still be able to specify a value
that can remove a previously specified type. Maybe a separate long
option --no-type or a magic value like -t any?
+ /* Write the entry's mandatory four header bytes. */
+ length = ptr[1];
+ grub_printf (Entry: Type=0x%02x Length=0x%02x Handle=0x%04x\n,
+ ptr[0], length, *(1 + (grub_uint16_t *)ptr));
Could you reverse the order in 1 + (grub_uint16_t *)ptr and in other
places too?
I'll replace all these pointer casts+dereferences with functions that
avoid alignment issues.
+ /* Dump of the formatted area (including the header) in hex. */
+ grub_printf ( Hex Dump: );
+ while (length-- 0)
+grub_printf (%02x, *ptr++);
+ grub_printf (\n);
+
+ /* Print each string found in the appended string list. */
+ while (ptr[0] != 0 || ptr[1] != 0)
I wonder do we have any ad hoc way to limit it? It looks like Linux
kernel does more sanity checks and does not blindly trust data.
The entry point structure has a two-byte field for total SMBIOS table
length, so that can put an upper limit on the string sets.
Thanks for the detailed review. I hope to be able to be able to send
a new revision later in the week.
Side note: A new major version of the SMBIOS specification was posted
last week which includes 64-bit addresses and such. I'm not planning
to try to add this at the moment, unless anyone has a need for it.
Thanks.
David
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
RE: [PATCH v2] Add a module for retrieving SMBIOS information
Hello, 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Actually, I had simplified the problem statement, to avoid complicating the discussion. Basically, we have enhanced the grub with a devicetree command that supplies a flattened device tree to the kernel (just like u-boot or others do in embedded world). http://www.denx.de/wiki/view/DULG/LinuxFDTBlob However, we need to pass different flattened device tree to the kernel based on different CHASSIS_TYPE. (because different chassis have different hardware components, slots etc that need to be handled differently). Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? I hope my problem statement clarification above makes it clearer. However, I think the problem is more generic - essentially depending on the current machine type, we may have to do different things on different platforms, such as: * Loading different kernels / initrd / device tree etc. * Passing different kernel parameters for: - different root fs mount points (root=/dev/sda[a/b/c/d]..) - enabling disabling different kernel features / drivers / subsystem (pci=[nocrs/use_crs]...) - etc. Thanks, Rajat -Original Message- From: Prarit Bhargava [mailto:pra...@redhat.com] Sent: Monday, February 09, 2015 4:44 AM To: David Michael Cc: grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov; Rajat Jain; Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information On 02/08/2015 01:54 PM, David Michael wrote: The following are two use cases from Rajat Jain rajatj...@juniper.net: 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? P. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Add a module for retrieving SMBIOS information
On 02/09/2015 10:27 AM, Rajat Jain wrote: Hello, 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Actually, I had simplified the problem statement, to avoid complicating the discussion. Basically, we have enhanced the grub with a devicetree command that supplies a flattened device tree to the kernel (just like u-boot or others do in embedded world). http://www.denx.de/wiki/view/DULG/LinuxFDTBlob However, we need to pass different flattened device tree to the kernel based on different CHASSIS_TYPE. (because different chassis have different hardware components, slots etc that need to be handled differently). Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? I hope my problem statement clarification above makes it clearer. However, I think the problem is more generic - essentially depending on the current machine type, we may have to do different things on different platforms, such as: * Loading different kernels / initrd / device tree etc. * Passing different kernel parameters for: - different root fs mount points (root=/dev/sda[a/b/c/d]..) - enabling disabling different kernel features / drivers / subsystem (pci=[nocrs/use_crs]...) - etc. Well I understand the request for different kernels, but 1) implies that you're adding additional kernel parameters based on the CHASSIS type? So I'm wondering why you're not making some boot time decision based on the CHASSIS type instead of a bootloader time decision. /me is not against the patchset. I think the idea of booting different kernels based on the HW sounds reasonable from a administration perspective. P. Thanks, Rajat -Original Message- From: Prarit Bhargava [mailto:pra...@redhat.com] Sent: Monday, February 09, 2015 4:44 AM To: David Michael Cc: grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov; Rajat Jain; Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information On 02/08/2015 01:54 PM, David Michael wrote: The following are two use cases from Rajat Jain rajatj...@juniper.net: 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? P. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
RE: [PATCH v2] Add a module for retrieving SMBIOS information
Hello Prarit, -Original Message- From: Prarit Bhargava [mailto:pra...@redhat.com] Sent: Monday, February 09, 2015 8:29 AM To: Rajat Jain Cc: David Michael; grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov; Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information On 02/09/2015 10:27 AM, Rajat Jain wrote: Hello, 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Actually, I had simplified the problem statement, to avoid complicating the discussion. Basically, we have enhanced the grub with a devicetree command that supplies a flattened device tree to the kernel (just like u-boot or others do in embedded world). http://www.denx.de/wiki/view/DULG/LinuxFDTBlob However, we need to pass different flattened device tree to the kernel based on different CHASSIS_TYPE. (because different chassis have different hardware components, slots etc that need to be handled differently). Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? I hope my problem statement clarification above makes it clearer. However, I think the problem is more generic - essentially depending on the current machine type, we may have to do different things on different platforms, such as: * Loading different kernels / initrd / device tree etc. * Passing different kernel parameters for: - different root fs mount points (root=/dev/sda[a/b/c/d]..) - enabling disabling different kernel features / drivers / subsystem (pci=[nocrs/use_crs]...) - etc. Well I understand the request for different kernels, but 1) implies that you're adding additional kernel parameters based on the CHASSIS type? So I'm wondering why you're not making some boot time decision based on the CHASSIS type instead of a bootloader time decision. Oh OK. I guess you are saying why not read the CHASSIS_TYPE in the kernel and take different paths depending on the value? The reason is because we may want to pass different kernel options that *exist today*. (E.g. different root file systems, or hw tuning parametes etc). Ideally once deployed, we neither want to change the bootloader, nor the kernel since that would require a recompilation which is best avoided. If something changes, it is much easier to change the grub config file which can be changed anytime, and thus we are requesting the *capability* to do it in a grub script or config file. /me is not against the patchset. I think the idea of booting different kernels based on the HW sounds reasonable from a administration perspective. Yup, understood. Also from admin perspective, I'm suggesting that we may need tune the kernel differently depending on the HW. Thanks, Rajat P. Thanks, Rajat -Original Message- From: Prarit Bhargava [mailto:pra...@redhat.com] Sent: Monday, February 09, 2015 4:44 AM To: David Michael Cc: grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov; Rajat Jain; Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information On 02/08/2015 01:54 PM, David Michael wrote: The following are two use cases from Rajat Jain rajatj...@juniper.net: 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? P. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Add a module for retrieving SMBIOS information
On 02/09/2015 12:38 PM, Rajat Jain wrote: Hello Prarit, -Original Message- From: Prarit Bhargava [mailto:pra...@redhat.com] Sent: Monday, February 09, 2015 8:29 AM To: Rajat Jain Cc: David Michael; grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov; Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information On 02/09/2015 10:27 AM, Rajat Jain wrote: Hello, 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Actually, I had simplified the problem statement, to avoid complicating the discussion. Basically, we have enhanced the grub with a devicetree command that supplies a flattened device tree to the kernel (just like u-boot or others do in embedded world). http://www.denx.de/wiki/view/DULG/LinuxFDTBlob However, we need to pass different flattened device tree to the kernel based on different CHASSIS_TYPE. (because different chassis have different hardware components, slots etc that need to be handled differently). Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? I hope my problem statement clarification above makes it clearer. However, I think the problem is more generic - essentially depending on the current machine type, we may have to do different things on different platforms, such as: * Loading different kernels / initrd / device tree etc. * Passing different kernel parameters for: - different root fs mount points (root=/dev/sda[a/b/c/d]..) - enabling disabling different kernel features / drivers / subsystem (pci=[nocrs/use_crs]...) - etc. Well I understand the request for different kernels, but 1) implies that you're adding additional kernel parameters based on the CHASSIS type? So I'm wondering why you're not making some boot time decision based on the CHASSIS type instead of a bootloader time decision. Oh OK. I guess you are saying why not read the CHASSIS_TYPE in the kernel and take different paths depending on the value? The reason is because we may want to pass different kernel options that *exist today*. (E.g. different root file systems, or hw tuning parametes etc). Ideally once deployed, we neither want to change the bootloader, nor the kernel since that would require a recompilation which is best avoided. If something changes, it is much easier to change the grub config file which can be changed anytime, and thus we are requesting the *capability* to do it in a grub script or config file. Ah, I get it. That certainly makes sense. I just thought there was some specific HW command that you always wanted executed on these boards. /me is not against the patchset. I think the idea of booting different kernels based on the HW sounds reasonable from a administration perspective. Yup, understood. Also from admin perspective, I'm suggesting that we may need tune the kernel differently depending on the HW. Thanks for the info :) P. Thanks, Rajat P. Thanks, Rajat -Original Message- From: Prarit Bhargava [mailto:pra...@redhat.com] Sent: Monday, February 09, 2015 4:44 AM To: David Michael Cc: grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov; Rajat Jain; Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information On 02/08/2015 01:54 PM, David Michael wrote: The following are two use cases from Rajat Jain rajatj...@juniper.net: 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? P. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Add a module for retrieving SMBIOS information
On 02/08/2015 01:54 PM, David Michael wrote: The following are two use cases from Rajat Jain rajatj...@juniper.net: 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the CHASSIS_TYPE information that is passed by the bios in the DMI / SMBIOS tables. Whups ... somehow stripped all the cc's on my original reply. why isn't 1) already in the kernel itself? P. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Add a module for retrieving SMBIOS information
On 02/08/2015 01:54 PM, David Michael wrote:
The following are two use cases from Rajat Jain rajatj...@juniper.net:
1) We have a board that boots Linux and this board itself can be plugged into
one of different chassis types. We need to pass different parameters to the
kernel based on the CHASSIS_TYPE information that is passed by the bios in
the DMI / SMBIOS tables.
why isn't 1) already in the kernel itself?
P.
2) We may have a USB stick that can go into multiple boards, and the exact
kernel to be loaded depends on the machine information (PRODUCT_NAME etc)
passed via the DMI.
* grub-core/commands/smbios.c: New file.
* grub-core/Makefile.core.def (smbios): New module.
* docs/grub.texi (smbios): New node.
(Command-line and menu entry commands): Add a menu entry for smbios.
---
Changes since v1:
* Removed formfeeds and quoted use cases in the commit messages as
suggested by Prarit Bhargava.
* Enabled building the module on all EFI platforms as suggested by Leif
Lindholm.
docs/grub.texi | 67
grub-core/Makefile.core.def | 7 +
grub-core/commands/smbios.c | 361
3 files changed, 435 insertions(+)
create mode 100644 grub-core/commands/smbios.c
diff --git a/docs/grub.texi b/docs/grub.texi
index 46b9e7f..f4e187f 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3830,6 +3830,7 @@ you forget a command, you can run the command
@command{help}
* sha256sum:: Compute or check SHA256 hash
* sha512sum:: Compute or check SHA512 hash
* sleep:: Wait for a specified number of seconds
+* smbios:: Retrieve SMBIOS information
* source:: Read a configuration file in same context
* test::Check file types and compare values
* true::Do nothing, successfully
@@ -4944,6 +4945,72 @@ if timeout was interrupted by @key{ESC}.
@end deffn
+@node smbios
+@subsection smbios
+
+@deffn Command smbios @
+ [@option{-t} @var{type}] @
+ [@option{-h} @var{handle}] @
+ [@option{-m} @var{match}] @
+ [ (@option{-b} | @option{-w} | @option{-d} | @option{-q} | @option{-s}) @
+ @var{offset} [@option{-v} @var{variable}] ]
+Retrieve SMBIOS information. This command is only available on x86 and EFI
+systems.
+
+When run with no options, @command{smbios} will print the SMBIOS table
entries
+to the console as the header values, a hex dump, and a string list. The
+following options can filter which table entries are printed.
+
+@itemize @bullet
+@item
+Specifying @option{-t} will only print entries with a matching @var{type}.
The
+type can be any value from 0 to 255. Specify a value outside this range to
+match entries with any type. The default is -1.
+@item
+Specifying @option{-h} will only print entries with a matching @var{handle}.
+The handle can be any value from 0 to 65535. Specify a value outside this
+range to match entries with any handle. The default is -1.
+@item
+Specifying @option{-m} will only print number @var{match} in the list of all
+filtered entries; e.g. @code{smbios -m 3} will print the third entry. The
list
+is always ordered the same as the hardware's SMBIOS table. The match number
+can be any positive value. Specify 0 to match all entries. The default is
0.
+@end itemize
+
+The remaining options print the value of a field in the matched SMBIOS table
+entry. Only one of these options may be specified. When they are used, the
+option @code{-m 0} is synonymous with @code{-m 1} to match the first entry.
+
+@itemize @bullet
+@item
+When given @option{-b}, print the value of the byte
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-w}, print the value of the word (two bytes)
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-d}, print the value of the dword (four bytes)
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-q}, print the value of the qword (eight bytes)
+at @var{offset} bytes into the matched SMBIOS table entry.
+@item
+When given @option{-s}, print the string table entry with its index found
+at @var{offset} bytes into the matched SMBIOS table entry.
+@end itemize
+
+If any of the options in the above list were given, a variable name can be
+specified with @option{-v} to store the value instead of printing it.
+
+For example, this will store and display the system manufacturer string.
+
+@example
+smbios -t 1 -s 4 -v system_manufacturer
+echo $system_manufacturer
+@end example
+@end deffn
+
+
@node source
@subsection source
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 42443bc..f87de70 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1023,6 +1023,13 @@
