I got a task to monitor hardware component of servers recelently and even try to convert SMBIOS to JSON modifying dmidecode.

As of today there are tools that can convert plain output to json.

One of them is jc https://pypi.org/project/jc/

# sudo jc dmidecode

will do the work.

Data can be convert to any other format with json result.

I think this issue can be closed.

>> I don't like the idea of building multiple binaries. It is a pain for
>> distributions to package and results in a lot of integration headaches in my
>> experience. I think it is much easier to have one binary with always the same
>> name. Distributions can enable specific features depending on their needs and
>> what libraries are available - they do that for a lot of packages already.

Sounds reasonable to me. I present it as an alternative in case there's a
specific goal/mandate to avoid additional dependencies/libs being involved.

>> Forking is the worst option and should be avoided at pretty much any cost.

Agreed: I generally treat it as a last-ditch option.

>> Specifically there are 3 hurdles to jump over:
>> 1* The dmidecode code was never designed for that.

This appears to be the case. It would take some time, but ~8500 lines of source
and headers isn't that bad (had to do something similar in the past for a 45,000
line app). The "hard part", IMHO, would be breaking it into logical,
incremental, digestible patches so the PR isn't one giant monster of a patch.
Do you have any particular preference between just having a global object/struct
that functions can call out to, versus a context variable/struct declared in
"main()" that get's passed around (i.e. would have to modify several function
prototypes to support this). I prefer the latter.

>> 2* Machine-readable is a generic term, we would need to settle on an actual
>> format. This appears to be a moving target, over time people have been asking
>> for SGML (I think), XML, JSON and now YAML (never heard of that one before).
>> Maybe a few more that I do not remember.  Depends on the trend of the moment.
>> I don't really want to support 4 different formats, although we certainly
>> want to design the new code in such a way that using a different format later
>> wouldn't be too much work.

I would argue that YAML would be best, given that:
A. It's arguably the easiest "structured format" for humans to read.
B. For all intents and purposes, it's a superset of JSON (i.e. can do anything
JSON can).
C. It supports comments, which is nice.
D. If additional formats (i.e. XML) are desired, it's trivial to convert the
internal object/representation of YAML to JSON, and from JSON to XML. There may
be a direct conversion too, but I personally haven't yet researched it
specifically.

>> 3* Even after deciding for a format, it says nothing about what the output
>> should look like. What should be the structure of the output?  What should be
>> a key, what should be a value? How do you order the entries?

Key/values, at least for an off-the-cuff response, would be similar to what's
already defined at the top-level for DMI types (i.e.
https://linux.die.net/man/8/dmidecode). Beyond that, more discussion/detail
would be required.

>> How to you deal with specification changes such as new DMI structures, new
>> entries added to older structures, renamed fields (yes it did happen before),
>> obsoleted fields?

I was considering this while putting together the original post/question. I was
thinking of using an API specification tool/standard to help with creating a
versioned API (i.e. acknowledge the specs will change or have to be versioned
long-term). I've used OpenAPI/Swagger quite a bit, and was debating whether
or not it could be re-purposed for the API specification pieces (formal spec,
versioning, etc.), without making use of the implementation stubs.

>> The GPL is about the source code, not the use of the tool. So I simply do not
>> understand your point about the risk, liability or propagating nature when it
>> just comes to including the dmidecode tool anywhere. You can build        
>> dmidecode and use it in any project regardless of the overall license of said
>> project.  All you need to do to comply with the GPL is provide the source   
>> code of dmidecode to your users upon request...                             

Under other circumstances, I would agree 100%. However, a couple of my clients 
have strict legal requirements that any GPLv2 based projects that are bundled  
into their products cannot be modified by a employee/contractor while that     
employee is working on their products, regardless of whether or not it's a     
standalone application, a library that is linked dynamically versus statically,
etc.                                                                           
                                                                               
It boils down to a "specific interpretation of the language of the GPL" (legal 
team spent a long time arriving at this conclusion), and any software that     
doesn't comply with these requirements is considered "tainted". If the project 
is solely licensed under GPLv2, LGPLv2; it's disqualified if it has changes    
present. Employee-modified software under the GPLv3/LGPLv3 is disqualified     
outright (i.e. even if dual-licensed), and Apache 2.0 and MIT are the only     
permissive licenses (so far) that get special treatment.                       

>> If you are talking about forking the code to include it in another tool, then
>> yes the GPL propagates. But forking is bad so I'm not going to do anything to
>> make it easier. If there's any improvement you would like to contribute to  
>> dmidecode, then please send patches to the list and they will be reviewed and
>> discussed there.                                                            

That's fair. I view forking as a last-ditch approach (i.e. if I want to add a  
major feature and the maintainers don't want it in mainline; only comes up when
there are differences in ideologies/priorities).                               

            

>> The only licensing change I will ever consider for dmidecode is if we ever
>> split the DMI table parser to a shared library, then that library would be 
>> licensed under the LGPL. Dmidecode itself is and will remain licensed under
>> the GPL.                                                                   

If the intent is to keep the project solely licensed under the GPLv2, 
there's nothing more to say. That being said, thank you for your time and      
feedback.                                                                      

Good day,

Are there any objections to adding the ability for "dmidecode" to be able to output data in JSON and/or YAML format? It seems (to me), *in specific use cases*, that it would be preferable to have the tool supplying the data of interest in a structured format, so that existing JSON/YAML parsers can be used on the output, in place of a dedicated per-application parser to interpret the human-readable output currently generated.

What are the maintainers' thoughts on this as an additional, non-default setting?