Good day, I'm working on a hobby project involving various dev boards, and I use `dmidecode` to help distinguish what "type" of board the software is running on, at run time. Some of the programs that run on the various boards are written in different languages, including C, C++, Golang, Python 2/3, and so on.
While there are dmidecode-specific parsers of varying levels of maturity for most of these languages, it would be preferable if `dmidecode` itself could directly export to YAML and/or JSON formats (no need to use various parsers with differing licenses). Would this feature be allowable, for example: * As a direct modification to `dmidecode` itself (i.e. additional feature; requires linking against additional libraries). * As a variant of `dmidecode`: i.e. wrap the feature in #ifdef's, and have the build/makefile script compile multiple binaries, including a "stock" `dmidecode`, and a second binary, `dmidecode_json` (only the latter would link against additional external libraries). Additional libraries are needed for the `dmidecode` package itself, but not the "stock" (i.e. no JSON/YAML capability) `dmidecode` binary. Could possibly result in two separate downstream packages derived from the same source. * Just fork/branch the source: I could also just fork the Github-mirror repo if this functionality isn't wanted/needed in the mainline repo. I imagine others would benefit from this feature, based on the existence of multiple dmidecode-specific parsers, so this route only makes sense if this feature doesn't belong in `dmidecode` mainline/master. What do the developers/maintainers think of these possible approaches to implementing such a feature? Thank you. -- -Matthew _______________________________________________ https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
