helpdmidecode - Support: sr #110185, Question: adding structured...

 
 

sr #110185: Question: adding structured output/logging (JSON, YAML)

Submitted by:  Matthew Giassa <mgiassa>
Submitted on:  Sat 25 Jan 2020 03:19:20 PM UTC  
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 27 Jan 2020 05:06:58 PM UTC, comment #5: 

This ticket can be closed (i.e. depends, at least with respect to me contributing personally, on sr #110184).

Matthew Giassa <mgiassa>
Mon 27 Jan 2020 04:07:49 PM UTC, comment #4: 

>> 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.

Matthew Giassa <mgiassa>
Mon 27 Jan 2020 03:33:08 PM UTC, comment #3: 

Pardon. Please disregard "comment #2", meant to post it to a separate ticket.

Matthew Giassa <mgiassa>
Mon 27 Jan 2020 03:32:18 PM UTC, comment #2: 

>> 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.                                                                      

Matthew Giassa <mgiassa>
Sat 25 Jan 2020 03:37:41 PM UTC, comment #1: 

>>  in a structured format

I should amend that to note "in a more commonly used or otherwise standardized structured format". The existing format is structured via indentation levels and blank newlines, but it would be preferable, for example, to just throw "json.loads()" at it, and be done with parsing.

Matthew Giassa <mgiassa>
Sat 25 Jan 2020 03:19:20 PM UTC, original submission:  

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?

Matthew Giassa <mgiassa>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mgiassa (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.6