The traditional way I've looked at DMI and SMBIOS information is through dmidecode (eg to check RAM DIMM information). I've done this interactively, and recently when I was inspired to automatically collect this information and dump it into our metrics system, I also used dmidecode as the core of the script (and in the process, I discovered that vendors put peculiar things into there). However, it turns out that for core DMI information you don't actually need dmidecode these days, because the Linux kernel puts it into sysfs.

In sysfs, DMI information is found at /sys/class/dmi/id, which is a symlink to /sys/devices/virtual/dmi/id. This will commonly expose the DMI 'BIOS', 'Base Board', 'Chassis', and 'System Information' sections as bios_*, board_*, chassis_*, and product_*. The sys_vendor file is the Vendor field from the DMI 'System Information' section. There's also a modalias file that summarizes much of this if you want to have it all in one spot.

(The various bits of modalias are prefixed with magic identifiers that you can find listed in drivers/firmware/dmi-id.c. The actual mapping of DMI information to Linux's internal kernel names for them is handled in drivers/firmware/dmi_scan.c, in dmi_decode().)

As you can see, this sysfs information doesn't capture everything that DMI can tell you about your system; for instance, it won't capture information on RAM DIMMs. If you want that sort of data, you're probably going to need to keep using dmidecode.

(Sysfs also has raw DMI information in /sys/firmware/dmi, but I haven't looked into what's there and how you would extract things from it. My view is that you might as well use dmidecode unless you have a good reason not to.)

One potential advantage or drawback of /sys/class/dmi/id is that much of the information in it is accessible without special permissions, while dmidecode requires you to be root. However, serial number and product UUID information is only accessible by root, so even if you're using /sys/class/dmi/id for reporting, you need to run as root if you want to capture that information. Interestingly, the board_asset_tag and chassis_asset_tag files are world readable, but in practice neither has useful content on most of our systems (although a couple do have specific identifying information in the chassis asset tag).

PS: In the future the Prometheus host agent will expose this information as metrics, due to this host agent pull and its associated dependencies. This closes a long standing host agent issue, which goes to show that sometimes very old issues do get resolved.