Some dmi keyword output look not readable about dmidecode-rs

[jrgerber]

Using the following script

#!/bin/bash
while read line
do
    echo -n "$line: ">> dmistrings.txt
    ./target/debug/dmidecode -s $line >> dmistrings.txt
    echo "========" >> dmistrings.txt
done < <(./target/debug/dmidecode -l)

Some keywords like system-uuid and chassis-type display internal debug information

...
system-uuid: Uuid(5F1B4CCE-81A8-5B9C-A549-41344AF919BD)
chassis-type: smbioslib::structs::types::system_chassis_information::ChassisTypeData { raw: 9, value: Laptop }
...

Yes this is an interesting issue. In each case there are variants. For example, UUID is normally a GUID. There is a case where it is all 0's and that has a special meaning. A match statement is easier to use with this type that is an enum. However, for display we have to decide if we need to report it as all 0's (this may be what dmidecode original does) or if it is OK or desirable to give more information like what the meaning of all 0's is.

There are types you will find where I named them ending in *Data. These are cases where there is an incomplete enum set of values. For example if a byte (0-255) represents ChassisType but not all 256 values have been assigned, I design it so you can know what the raw value is. If for example there is no value assigned for ChassisType 234, raw will show the value "234" and value will say "None". This might be a case where our library is DMTF SMBIOS 3.4.0 but 3.5.0 came out and we've not added the new assignment for 234. We don't punish the consumer in this case for the library not being up to date but offer the raw value.

So in this case, do we output "234" when we do not know the assigned name?

[jrgerber]

This is a good case study to see what the original DMIDECODE does and then decide if we should improve for greater usability and if so, how?

There is an option "nosysfs" and I have not looked yet but it might mean to use the /sys/class/dmi/id files (which are normal user accessible). If this is what that option does, then the contents of the files are used to report these fields. So being consistent in our output with what the OS fills in those files might be the best option (maybe not get fancy with better output but maintain original functionality). We can always add more options of our own.

[jczuluag]

Hi @jrgerber , seems like this is not a bug as such right?

[jrgerber]

Hi @jrgerber , seems like this is not a bug as such right?

I think it is a very valid bug. I think we should make the output identical to the original dmidecode.

Being identical to dmidecode allows people to replace their dmidecode with a Rust version. We can always add verbose option improvements too.

[jczuluag]

This repo has to be updated to reflect the changes from smbios-lib to fix this issue