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

Chad Versace chad.versace at intel.com
Tue Feb 10 12:09:05 PST 2015


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.

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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/waffle/attachments/20150210/824dc2d4/attachment.sig>


More information about the waffle mailing list