Quoting Tvrtko Ursulin (2018-06-25 18:25:46) > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > This Kconfig option was added to protect the implementation specific > internals from user expectations but so far it was mostly hassle. > > Remove it so it is possible to debug request submission on any kernel > anywhere. Our job is not to let bugs into the wild ;) > This adds around 4k to default i915.ko build but should have no > performance effects due inactive tracepoints being no-op-ed out and out- > of-line. > > Users should remember tracepoints which are close to low level i915 > implementation details are subject to change and cannot be guaranteed. That's the caveat that I feel needs fleshed out. Burying it had the advantage of making it quite clear that you had to opt in and pick up the pieces when it inevitably breaks. What is wanted and what can we reasonable provide? If the tracepoints needs to undergo major change before the next LTS, let alone for the life of that LTS... If we know what is wanted can we define that better in terms of dma_fence and leave lowlevel for debugging (or think of how we achieve the same with generic bpf? kprobes)? Hmm, I wonder how far we can push that. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
