[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