Re: [waffle] [PATCH 7/7] nacl: add implementation for waffle_dl_sym
On 6 February 2015 at 19:44, Chad Versace chad.vers...@intel.com wrote: ... The way that Waffle's Linux and Mac platforms work today, the user doesn't have to call waffle_dl_can_open(). When the user calls waffle_dl_sym(), Waffle internally calls dlopen() if the user hasn't called waffle_dl_sym() on that library before. Thank you for the correction Chad. I have to respectfully disagree for one bit - waffle_dl_sym does not directly call waffle_dl_can_open. The former does trigger an waffle_error as an invalid dl is selected, while the latter should not*. Currently Tapani directly executes nacl_dl_can_open within nacl_dl_sym - thus no error is emitted for the latter. Imho he can resolve this by following following cgl/linux example. Cheers Emil [*] Upon closer look it seems that cgl does set a waffle_error on waffle_dl_can_open. I will send out a patch later on today. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On Tue, Feb 10, 2015 at 3:09 PM, Chad Versace chad.vers...@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. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] Add the waffle_teardown API
On 02/03/2015 05:14 PM, Emil Velikov wrote: Hi Chad, Here is to another waffle API - waffle_teardown In summary: - It pairs up with waffle_init - Cleans up some memory leaks - Allows one to switch between platforms without the need to exit the program. Let me know if you'd like me to resend the patches and/or rebase them on top of any other branch. Branch is merged. Thanks. signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
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? signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/08/2015 04:50 PM, 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. For anyone who would like to experiment with Frank's work, I've created a throw-away 'pu' branch (proposed updates) and merged Frank's 'ps_core' branch there. The 'pu' branch isn't stable and may be rewritten at any time. signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/10/2015 01:08 PM, Frank Henigman wrote: On Tue, Feb 10, 2015 at 3:09 PM, Chad Versace chad.vers...@intel.com wrote: 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. This all sounds good to me. signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
