On Tue, Feb 10, 2015 at 3:09 PM, Chad Versace <[email protected]> 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. _______________________________________________ waffle mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/waffle
