lkml.org 
[lkml]   [2020]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option
On Sun, Jun 28, 2020 at 02:46:16PM -0400, Steven Rostedt wrote:
> >
> > By now everyone has learned to use bpf_trace_printk() and expects
> > to see the output in /sys/kernel/debug/tracing/trace.
> > It's documented in uapi/bpf.h and various docs.
>
> Re-teach them, or are you finally admitting that the tracing system is
> a permanent API? This is the reason people are refusing to add trace
> points into their subsystems. Because user space may make it required.
>
> I see no reason why you can't create a dedicated BPF tracing instance
> (you only need one) to add all your trace_array_printk()s to.

All bpf helpers are stable api. We cannot remove bpf_trace_printk() and
cannot change the fact that it has to print into /sys/kernel/debug/tracing/trace.
If we do so a lot of users will complain. Loudly.
If you really want to see the flames, go ahead and rename 'trace_pipe'
into something else.
This has nothing to do with tracing in general and tracepoints.
Those come and go.
If you really want to nuke trace_printk from the kernel we need time
to work on replacement and give users at least few releases of helper
deprecation time. We've never done in the past though.
There could be flames even if we deprecate it gradually.
Looking how unyielding you're about this banner I guess we have to start
working on replacement sooner than later. Oh well.

\
 
 \ /
  Last update: 2020-06-28 21:22    [W:0.078 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site