Am 13.08.19 um 10:25 schrieb Chris Wilson: > Quoting Koenig, Christian (2019-08-13 07:59:28) >> Am 12.08.19 um 16:53 schrieb Chris Wilson: >>> Quoting Koenig, Christian (2019-08-12 15:50:59) >>>> Am 12.08.19 um 16:43 schrieb Chris Wilson: >>>>> Quoting Koenig, Christian (2019-08-12 15:34:32) >>>>>> Am 10.08.19 um 17:34 schrieb Chris Wilson: >>>>>>> Move the duplicated code within dma-fence.c into the header for wider >>>>>>> reuse. In the process apply a small micro-optimisation to only prune the >>>>>>> fence->cb_list once rather than use list_del on every entry. >>>>>>> >>>>>>> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >>>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> >>>>>>> --- >>>>>>> drivers/dma-buf/Makefile | 10 +- >>>>>>> drivers/dma-buf/dma-fence-trace.c | 28 +++ >>>>>>> drivers/dma-buf/dma-fence.c | 33 +-- >>>>>>> drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 32 +-- >>>>>>> include/linux/dma-fence-impl.h | 83 +++++++ >>>>>>> include/linux/dma-fence-types.h | 258 ++++++++++++++++++++ >>>>>>> include/linux/dma-fence.h | 228 +---------------- >>>>>> Mhm, I don't really see the value in creating more header files. >>>>>> >>>>>> Especially I'm pretty sure that the types should stay in dma-fence.h >>>>> iirc, when I included the trace.h from dma-fence.h or dma-fence-impl.h >>>>> without separating the types, amdgpu failed to compile (which is more >>>>> than likely to be simply due to be first drm in the list to compile). >>>> Ah, but why do you want to include trace.h in a header in the first place? >>>> >>>> That's usually not something I would recommend either. >>> The problem is that we do emit a tracepoint as part of the sequence I >>> want to put into the reusable chunk of code. >> Ok, we are going in circles here. Why do you want to reuse the code then? > I am reusing the code to avoid fun and games with signal-vs-free. Yeah, but that doesn't seems to be valid. See the dma_fence should more or less be a contained object and you now expose quite a bit of the internal functionality inside a headers. And creating headers which when included make other drivers fail to compile sounds like a rather bad idea to me. Please explain the background a bit more. Thanks, Christian. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
