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

[Frank Henigman]

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.