Hi,
thanks for feedback.
On Mon, Jul 3, 2023 at 6:57 PM Erwan Velu <erwanalia...@gmail.com> wrote:
> Hey,
> first of all, I like the idea and it could be super helpful as we are
> many to parse dmidecode output as text which isn't really good.
>
> I tried your PR, here come my feedback :
>
> 1/ you are using iterators defined in loops which breaks the
> compilation on older GCC compilers like the 4.8 on Rhel 7.
> It would be cool to keep it compatible with older compilers so anyone
> can use this feature
> There are several build failures as per the following :
>
> dmioutput.c:215:13: error: 'for' loop initial declarations are only
> allowed in C99 mode
> for (int i = 0; key[i]; i++) {
>
Sure thing. I will make it compatible with older compilers.
> 2/ when specifying a given type, all other types are reported empty
> like when calling "dmidecode -t 17 --json"
> It would be cool not to print empty data structures
>
I know about this issue. It is my plan to not print empty data structures.
>
> 3/ the nasted hashes make it a bit complicated to manipulate with jq :
> I tried to extract some values from matching a particular type, that's
> not trivial
>
>
I agree. I already have a plan to move values of "header" to parent item.
Output will be similar to output from jc. It will look like this:
{
[
{
"handle": 19,
"type": 2,
"length": 15,
"description": "Base Board Information",
"active": true,
"values": {
"manufacturer": "Foo",
...
},
}
]
}
> 4/ be careful of the code indent in your PR, you're breaking the coding
> style
>
>
Oh no. I thought that my IDE is smart enough and it is able to detect the
style of indentation
of imported projects and alter settings for related projects. Never mind. I
will fix it. Will
it be enough to fix it in next commit or is it necessary to fix it in all
commits?
Open questions:
1) What about "handle" values? Could it be a number? Or should I convert it
to string
with hexadecimal representation? I lean towards hex values to be
consistent
with text format and compatible with jc.
2) There is nothing printed in pr_info() and pr_comment(), when --json is
used. Is it acceptable?
3) I converted all printf() functions from dmidecode.c to pr_printf() and
it does print anything,
when --json is used now. I would like to put such information to output
somehow, when --json
is used, but I have to admit that this will not be easy. Any suggestions?
Jiri
> Le lun. 3 juil. 2023 à 18:19, Jiri Hnidek <jhni...@redhat.com> a écrit :
> >
> > Hi All,
> > I created another PR https://github.com/jirihnidek/dmidecode/pull/2,
> where
> > "dmidecode --json" uses json-c. It is still draft. I need to do some
> > refactoring and testing. Do not expect that it will work seamlessly with
> > all combinations of CLI options.
> >
> > Example of output is here:
> > https://gist.github.com/jirihnidek/2269d97f9cc9be9dc74b310eceb9e2d0
> >
> > I would like to get your feedback.
> >
> > I hope that such will be accepted (after addressing all requests and
> > comments). We would not like to create some fork of dmidecode. Having the
> > option to do output of dmidecode without any other wrapper like (
> > https://kellyjonbrazil.github.io/jc/) is important to us.
> >
> > Thanks in advance,
> >
> > Jiri
> >
> > On Fri, Jun 23, 2023 at 4:45 PM Jiri Hnidek <jhni...@redhat.com> wrote:
> >
> > > Hi,
> > > I'm working on machine readable output of dmidecode. I added the --json
> > > CLI option. You can see my POC here:
> > >
> > > https://github.com/jirihnidek/dmidecode/pull/1
> > >
> > > Example of output can be seen here:
> > >
> > > https://gist.github.com/jirihnidek/02c7620a5c2cf06752ccea877b35cc84
> > >
> > > As you can see there are no dependencies to any other library, but some
> > > information is missing in the output (e.g. handle, DMI type), and
> there are
> > > other issues.
> > >
> > > I would like to ask if you would be interested adding this to upstream
> > > version of dmidecode?
> > >
> > > I would like to do proper implementation using the json-c library:
> > > https://github.com/json-c/json-c This is a small library that is part
> of
> > > most Linux distributions. Could adding dependency on json-c be
> acceptable?
> > >
> > > Adding support for machine readable output to dmidecode would be much
> > > appreciated, because our tools like subscription-manager [1] (core
> part of
> > > all RHEL) has to parse human readable output of dmidecode and it is
> > > sub-optimal. There are other projects trying to parse output of
> dmidecode,
> > > e.g. py-dmidecode: https://pypi.org/project/py-dmidecode/
> > >
> > > Thanks in advance
> > >
> > > Jiri
> > >
> > > [1] https://github.com/candlepin/subscription-manager/
> > >
> > > --
> > > Jiri Hnidek
> > > Senior Software Engineer, Team Candlepin, Red Hat
> > >
>
>
