lkml.org 
[lkml]   [2018]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] do not call trace_printk on non-debug build
We have seen many cases vendor have shipped kernel/drivers with it, and
have to clean up that every year. This was brought up in an internal
discussion and Greg suggested have some feedback from upstream about what
should be taken to prevent this globally besides fixing individual drivers.
From him "I think this change makes sense at a high level, but there could
be non-obvious reasons why this isn't the way things are handled right now."
On Tue, Apr 24, 2018 at 11:51 AM Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 24 Apr 2018 11:08:10 -0700
> Wei Wang <wvw@google.com> wrote:

> > From: Wei Wang <wvw@google.com>
> >
> > trace_printk will cause trace_printk_init_buffers executed in kernel
> > start, which will increase memory and also show bad warnings in
> > production kernel.
> >

> NAK!

> Where is trace_printk() being used to trigger this?

> trace_printk() is to be added while debugging, but one should not need
> to enable DEBUG to use it. But it should be removed when finished.


Yeah, ideal case is it *should* be removed, but if this is not for
production use, does it make sense we limit the usage with DEBUG?


> -- Steve

> > Signed-off-by: Wei Wang <wvw@google.com>

\
 
 \ /
  Last update: 2018-04-24 21:03    [W:0.092 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site