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