Re: [PATCH] tracing: remove tracing_is_on export

[Greg Kroah-Hartman]

On Thu, Jul 25, 2024 at 09:26:09AM -0400, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 14:52:24 +0200
> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Thu, Jul 25, 2024 at 08:31:02AM -0400, Steven Rostedt wrote:
> > > On Thu, 25 Jul 2024 11:36:08 +0200
> > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >   
> > > > The function tracing_is_on() is only called by in-kernel code, not by
> > > > any modules, so no need to export it as a symbol at all.  
> > > 
> > > Hmm, this is part of the debugging code along with:
> > > 
> > >  tracing_on();  tracing_off();
> > > 
> > > I had it exported in case a module needed to use it in debugging.  
> > 
> > What module?  There is no in-kernel user of it as a module that I could
> > find, what am I missing?
> >
> 
> Any module ;-)
> 
> It's for debugging. Just like trace_printk(). Something you would add to
> debug a module and then delete it before submitting. It's why I put the
> prototype into kernel.h. It's one of functions that can be handy during
> development. It's not supposed to be submitted into the kernel.
> 
> Granted, tracing_is_on() is probably the least likely one to be used, but I
> added it with the package, and I have actually used it for debugging a few
> times.

Generally, we don't allow symbols that are not actually being used in
the kernel tree?  tracing_is_on() is a "code flow" type of thing, where
code can operate differently if it is enabled or not.

And I would argue that tracing_on() and tracing_off() should also not be
allowed to be in a module, why would you want that?  Just enable/disable
it from userspace when doing your testing, IF you have permission to do
so.

thanks,

greg k-h