<div dir="ltr">Okay. I'll send out a v2 shortly.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 9:24 AM, Chad Versace <span dir="ltr"><<a href="mailto:chad.versace@intel.com" target="_blank">chad.versace@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/31/2015 09:51 AM, Dylan Baker wrote:<br>
<span class="">><br>
><br>
> On Wed, Dec 30, 2015 at 4:32 PM, Chad Versace <<a href="mailto:chad.versace@intel.com">chad.versace@intel.com</a> <mailto:<a href="mailto:chad.versace@intel.com">chad.versace@intel.com</a>>> wrote:<br>
><br>
>     On 12/27/2015 07:49 AM, Frank Henigman wrote:<br>
</span>>     > On Wed, Dec 16, 2015 at 8:37 PM,  <<a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a> <mailto:<a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a>>> wrote:<br>
>     >> From: Dylan Baker <<a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a> <mailto:<a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a>>><br>
<span class="">>     >><br>
>     >> This adds some code to print a JSON formatted version of data provided<br>
>     >> by wflinfo.<br>
>     >><br>
</span>>     >> Signed-off-by: Dylan Baker <<a href="mailto:dylanx.c.baker@intel.com">dylanx.c.baker@intel.com</a> <mailto:<a href="mailto:dylanx.c.baker@intel.com">dylanx.c.baker@intel.com</a>>><br>
<span class="">>     >> ---<br>
>     >>  src/utils/wflinfo.c | 174 +++++++++++++++++++++++++++++++++++++++++++++++++++-<br>
><br>
><br>
><br>
>     >> +static void<br>
>     >> +json_print_context_flags(void)<br>
>     >> +{<br>
>     >> +    int flag_count = sizeof(flags) / sizeof(flags[0]);<br>
><br>
>     This should be<br>
><br>
>             const int flag_count = ARRAY_SIZE(flags);<br>
><br>
>     Optionally, you could even remove the flag_count variable altogether<br>
>     and use ARRAY_SIZE(flags) everywhere. But it doesn't really matter.<br>
><br>
><br>
> This was copied from the original print_context_flags function. Should I chang ethat to ARRAY_SIZE as well (presumably in a separate patch)?<br>
<br>
</span>Yes. It would be nice if you cleaned up print_context_flags in a separate patch.<br>
<div><div class="h5"><br>
>     >> +<br>
>     >> +    printf("[\n");<br>
>     >> +    for (int i = 0; i < flag_count; i++) {<br>
>     >> +        if ((flags[i].flag & context_flags) != 0) {<br>
>     >> +            printf("        \"%s\"", flags[i].str);<br>
>     >> +            context_flags = context_flags & ~flags[i].flag;<br>
>     >> +            if (i != flag_count) {<br>
>     >> +                printf(",\n");<br>
>     >> +            }<br>
>     >> +        }<br>
>     >> +    }<br>
>     >> +    for (int i = 0; context_flags != 0; context_flags >>= 1, i++) {<br>
>     >> +        if ((context_flags & 1) != 0) {<br>
>     >> +            printf(",\n");<br>
>     >> +            printf("        0x%x", 1 << i);<br>
>     >> +        }<br>
>     >> +    }<br>
>     >> +    printf("    ]");<br>
><br>
>     Like Frank said, it would be nice if the json code didn't duplicate so much of the<br>
>     original code. But, because you're not confident yet in C (as you say in the cover letter),<br>
>     I'll accept the duplication in this function. I'll offer to deduplicate the code myself if the patches<br>
>     go upstream.<br>
><br>
><br>
> I'm curious what the (or a) good approach would be to fix this. I<br>
> tried making a similar implementaiton in python (which I'm more<br>
> comfortable with) and still had a hard time coming up with a good way<br>
> to share code.<br>
><br>
> Personally I find being thrown in the deep in the best way to learn<br>
> to swim, so if you could point me in the right (or at least a good)<br>
> direction I'd like to take a stab at it.<br>
<br>
</div></div>Honestly, I also don't see a clean way to deduplicate the code for the<br>
variable-length fields. Perhaps careful use of template strings that the<br>
loops fill out with sprintf.<br>
<br>
I suggest you don't worry about deduplication in this patch series, and<br>
we can revisit it after the patches land. It would be silly to stall the json<br>
output due to duplication of a tiny chunk of code.<br>
<span class=""><br>
<br>
>     > I think some key strings should be a bit more specific or nested, like<br>
>     > "opengl version:" or "opengl : { version :" instead of just "version"<br>
>     > in case we expand some day to include things like egl version.<br>
><br>
>     I agree. I also think the non-OpenGL key strings ("platform" and "api")<br>
>     should be prefixed with "waffle", just as they are in the normal wflinfo<br>
>     output.<br>
><br>
><br>
> I started changing this locally after Frank's comments. My plan was<br>
> to nest waffle specific information inside a waffle dict, OpenGL<br>
> (including ES) inside of an opengl dict, and then leave room for<br>
> other information to be in it's own data structures (say glx or egl)<br>
><br>
> something like:<br>
> {<br>
>      "waffle": {<br>
>           "platform": "gbm"<br>
>      },<br>
>      "gl": {<br>
>           "version": 3.1,<br>
>           "profile": "core"<br>
>      }<br>
> }<br>
><br>
> Does that seem reasonable?<br>
<br>
</span>That looks good to me.<br>
<br>
</blockquote></div><br></div>