[Intel-gfx] uABI / Removing DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig

[Joonas Lahtinen]

Quoting Steven Rostedt (2018-12-19 21:22:57)
> On Wed, 19 Dec 2018 12:08:18 +0200
> Joonas Lahtinen <joonas.lahtinen at linux.intel.com> wrote:
> 
> > To me, it seems almost as if folks are too preoccupied with thinking if
> > we somehow can do this through tracepoints, to stop and actually think
> > if we should.
> 
> Regardless of whether it should or shouldn't, one solution to this is
> to make the trace event in question record basically nothing but a
> pointer.
> 
> DECLARE_EVENT_CLASS(i915_hw_request,
>             TP_PROTO(struct i915_request *rq),
>             TP_ARGS(rq),
> 
>             TP_STRUCT__entry(
>                                 __field(void *, rq)
>                              ),
> 
>             TP_fast_assign(
>                         __entry->rq = rq;
>                            ),
> 
>             TP_printk("rq=%p", __entry->rq)
> );
> 
> Define the events from that:
> 
> DEFINE_EVENT(i915_hw_request, i915_request_submit,
>              TP_PROTO(struct i915_request *rq),
>              TP_ARGS(rq)
> );
> 
> 
> No tool can use that information. But for those that want to, you make a
> separate module that you can load that has:

That's a nifty idea.

If the module is built out-of-tree from gpuvis package, you'd
still lose the functionality on kernel update, though. But I
guess it'd then be a problem of the distro that chooses to
package gpuvis/gputop/whatever profiler in stable manner.

On the other hand, if we would have eBPF based (kudos to Chris for
mentioning) module in-tree for userspace to hook to, it would
make things more easily fixable from userspace

You could for example automate the download a matching piece
of eBPF to execute on the module for a kernel version.

So the lines definitely get blurred here, about what is breaking
userspace and what is userspace deliberately setting itself up for
breaking.

*But* before we seek for a judgement on that. We're still having
the peculiarity that the tracepoints would shortly have to be
generated based from hardware event log.

Do you have an idea how to solve that elegantly? Or do you rule such
thing to be outside of the scope for tracepoints?

So if we still end up with a hybrid solution where another uAPI is
needed for hardware events, I'm not sure if above is worthy the hassle
when we can just add to the other uAPI the same events.

Regards, Joonas