On 23 August 2016 at 12:26, Tapani Pälli <tapani.pa...@intel.com> wrote: > > On 08/23/2016 12:52 PM, Tapani Pälli wrote: >> >> On 08/18/2016 01:28 PM, Emil Velikov wrote: >>> >>> On 21 June 2016 at 11:33, Emil Velikov <emil.l.veli...@gmail.com> wrote: >>>> >>>> On 16 May 2016 at 11:57, Emil Velikov <emil.l.veli...@gmail.com> wrote: >>>>> >>>>> On 16 May 2016 at 11:54, Emil Velikov <emil.l.veli...@gmail.com> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> While looking at the gbm/egl I've noticed a few interesting bits. >>>>>> - We do NULL checking for values that are guaranteed by API to be >>>>>> non-NULL. >>>>>> - wcore_*_init does not need a return type, plus in some places we >>>>>> were >>>>>> not calling it in the correct time. >>>>>> - wcore_*_teardown is a simple wrapper around assert, which (at the >>>>>> time the function should be called) is too late/not needed. >>>>>> >>>>>> So this series simplifies these, giving us a nice -350 line count ;-) >>>>>> >>>>>> The whole thing can be found in >>>>>> https://github.com/evelikov/waffle/tree/for-upstream/core-cleanups >>>>>> >>>>> For some reason git send-email seems to be choking on patches 08/13 >>>>> and 09/13. Please check those out via the above repo or let me know if >>>>> you'd prefer them in other format. >>>>> >>>> I might have gone overboard (too much) folding the error label(s) in >>>> 09/13 "core: remove wcore_*_init() return type". I can split those up >>>> if people prefer. >>>> >>> Humble poke. >> >> >> >> Patches 1 (cleanup) and 3-7 (do not check null since api_check_entry did >> it already): >> >> Reviewed-by: Tapani Pälli <tapani.pa...@intel.com> >> >> (I will check the rest from the repo) > > > Also R-B to 12 and 13. > Thanks Tapani. Hope we can find someone with commit access to push these.
> Question about "core: remove wcore_*_teardown()" patch: > > Is it possible that core classes will have allocations or some other stuff > in their constructor that then needs cleanup in dtor in the future? If it > happens then all of this infrastructure needs to be put back .. I'm just > thinking if this is OK from that perspective? > I cannot think of any case that would require us to bring these back since: - waffle itself is meant to have/store little to no state (only some *_platform can take more than 100 bytes) with the memory allocation done in the platform rather than wcore. I.e. wcore does not and should not [mc]alloc anything that needs to be freed. - the wcore api only 'links' the primitives initially thus there is nothing that could/should be teardown. One day as we add MT support we might need to rethink things, but we would need a serious work either way, imho. Emil _______________________________________________ waffle mailing list waffle@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/waffle