On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman <[email protected]> wrote: > 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.
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. _______________________________________________ waffle mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/waffle
