Hi Jerry, Thanks for your feedback.
On Thu, 3 Jul 2025 17:40:31 -0600, Jerry Hoemann via dmidecode-devel wrote: > On Wed, Jul 02, 2025 at 05:46:40PM +0200, Jean Delvare wrote: > > Starting with SMBIOS specification version 3.8.0, the term "BIOS" is > > replaced by the more generic term "Firmware" or "Platform Firmware". > > Update all references accordingly. > > While the new 3.8 specification field names are more descriptive, > it is unfortunate as the change will potentially break scripts > that look for the old names. I would hope that such scripts use the CLI, and specifically options --string and --type. These are available since 2005. I left the string and type keywords unchanged on purpose so that the CLI stays compatible. Do you know of any specific script which would be broken? I checked on my systems and found only 5 packages which depend on dmidecode: * virt-what parses the text output of dmidecode. It does not use the CLI, but it is not affected by these changes. * suseconnect makes use of the CLI (options -t and -s) and doesn't check anything related to BIOS/firmware, and is therefore not affected by these changes. * inxi also makes use of the CLI as far as I can see (-t chassis -t baseboard -t processor) then it parses the output, but these types are not related to BIOS/firmware so it isn't affected by the changes. * rdma-core uses options -t system, -t 204 and -t 2, none of these are BIOS/firmware-related, so it isn't affected either. * fwts dumps the output of dmidecode to a log file, without processing it, so it doesn't care. So at least these are safe. Of course there could be many custom scripts out there, but they shouldn't be too hard to adjust to accommodate these changes. Note that, every time a dmidecode change affects compatibility, it is clearly labeled as such in the NEWS file at release time, so people using dmidecode in scripts or other tools have a chance to notice and adjust their code accordingly if needed. -- Jean Delvare SUSE L3 Support
