[waffle] [wflinfo] [RFC] platform-specific info from wflinfo

[Frank Henigman]

On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman <fjhenigman at google.com> wrote:
> On Tue, Feb 10, 2015 at 3:09 PM, Chad Versace <chad.versace at intel.com> wrote:
>> On 02/10/2015 10:31 AM, Dylan Baker wrote:
>>> I like this idea, it would be convenient for piglit to be able to assume
>>> waffle info can provide all of the information we currently call out to
>>> multiple binaries for.
>>
>> Yes, Piglit wants this. I imagine more users will begin using it too.
>>
>>> On Sun, Feb 08, 2015 at 07:50:15PM -0500, Frank Henigman wrote:
>>>> I'd like to extend wflinfo so it can print platform-specific
>>>> information and eventually be able to replace glxinfo, eglinfo and the
>>>> like (I only know what's on linux).  There would be a new flag to
>>>> request the platform-specific output in addition to the existing
>>>> output.  For example on glx you'd see glx extensions, on egl you'd see
>>>> egl extensions.
>>>> I've started two different implementations and I'd like to know which
>>>> is preferred before I go any farther.  Or if there's a better idea
>>>> than either of my approaches.  I've dubbed the two approaches "native"
>>>> and "core."
>>>>
>>>> native
>>>> - all the work is done in wflinfo, no changes to waffle api
>>>> - use waffle_display_get_native() to access platform-specific stuff
>>>> - pro: changes limited to wflinfo, doesn't clutter up the rest of waffle
>>>> - con: some duplicate code to open libraries and lookup symbols
>>>> - https://github.com/fjhenigman/waffle/tree/ps_native
>>>>
>>>> core
>>>> - add waffle_display_print_info() to waffle api
>>>> - add print_info() method to each platform
>>>> - pro: less code, no duplication
>>>> - con (perhaps): some wflinfo functionality is now in core waffle
>>>> - https://github.com/fjhenigman/waffle/tree/ps_core
>>>>
>>>> I'm leaning toward "core" because there is less code.  We get to
>>>> leverage the platform libraries and functions already stored in waffle
>>>> platform structs.  But if the consensus is it's cleaner to keep this
>>>> stuff in wflinfo I'm ok with that too.
>>
>> I prefer "core" too. Not for the sake of less code, but because I like
>> the idea of it being available as core API.
>>
>> I've begun adding Github comments to your ps_core branch. We can do
>> review Github-style, if you like. If you send patches to the list,
>> that's ok too.
>
> Thanks for feedback.  From here on I'll send patch sets to the list.
> I'll incorporate any github suggestions in the first such set.
>
>> I see two significant design decisions that need to be made:
>>
>>   Issue #1: Should Waffle provide a query mechanism for the native
>>   platform info? Or should it just dump the info as a well-formatted
>>   string?
>>
>>      Resolved: I like the way that your waffle_display_print_info() just dumps
>>      the information as a string. That's much simpler and more
>>      extensible than a true query mechanism.
>>
>>   Issue #2: How should Waffle give that information string to the user?
>>
>>      I think hardcoding stdout as the destination for the information
>>      is too restrictive. A very simple alternative would be that
>>      waffle_display_print_info() return a C-string that the user is
>>      required to free. Or perhaps the user should pass a string
>>      buffer and max length to waffle_display_print_info(),
>>      similar to snprintf(). Or maybe something completely different.
>>      What do you think is the best approach?
>
> Returning a string.  If the user has to supply a buffer they won't
> know how big it needs to be.
> I think the function will want an enum or bitmask parameter for
> controlling, for example, verbosity.
> If we ever want a fancy query interface that returns structs instead
> of a string, we'll be able to
> re-implement the string-returning function over that interface for
> backward compatibility.
> I suggest calling this one waffle_display_info_string() instead of
> taking a name we might want to
> use later, like waffle_display_info or waffle_display_query.

Looks like Issue #3 is the format of the information.  I thought it
was given we should duplicate existing glxinfo/eglinfo/etc as closely
as possible, in order to be a drop-in replacement, but if I follow the
suggestions Chad made on github
(https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872)
we'll be diverging.  "Improving" on existing tools is ok with me - I
don't have a huge investment in code to parse their output - but I
wonder if others feel differently.