From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: David Laight <David.Laight@aculab.com>,
'Nicolas Boichat' <drinkcat@chromium.org>,
"dianders@chromium.org" <dianders@chromium.org>,
"groeck@chromium.org" <groeck@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
"Guilherme G. Piccoli" <gpiccoli@canonical.com>,
Kars Mulder <kerneldev@karsmulder.nl>,
Kees Cook <keescook@chromium.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Thomas Gleixner <tglx@linutronix.de>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
Will Deacon <will@kernel.org>, Yue Hu <huyue2@yulong.com>,
"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5] kernel/trace: Add DISALLOW_TRACE_PRINTK make option
Date: Mon, 24 Aug 2020 16:42:01 +0300 [thread overview]
Message-ID: <20200824134201.GM1891694@smile.fi.intel.com> (raw)
In-Reply-To: <20200824092828.4386bd25@oasis.local.home>
On Mon, Aug 24, 2020 at 09:28:28AM -0400, Steven Rostedt wrote:
> On Mon, 24 Aug 2020 08:26:13 +0000
> David Laight <David.Laight@ACULAB.COM> wrote:
>
> > Since the objective seems to be to ensure there are no
> > calls to trace_printk() in the git tree, but to allow
> > them in uncommitted sources. Why not use a config option
> > and rely on rand-config builds to detect any 'accidental'
> > commits?
>
> Because we don't want distros to ship with disallowing trace_printk,
> where someone finds a bug, sends the config to a developer, who then
> adds trace_printk() just to find that they can't use it.
>
> The point of avoiding a config was to keep the burden of having the
> developer needing it and having to then modify the config given to them.
>
> Also, it would then prevent those developing modules from using
> trace_printk() in their module if they build against one of these
> kernels.
>
> Finally, there's debug code in the kernel that legitimately uses
> trace_printk(), and those randconfigs will trigger on them.
How making it make's option prevent some "smart" distros to achieve the same?
AFAIU any compile-time knob will allow to build a kernel w/o a feature and you
are against of such kernel builds in distros. Catch-22?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-08-24 13:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 2:59 [PATCH v5] kernel/trace: Add DISALLOW_TRACE_PRINTK make option Nicolas Boichat
2020-08-24 8:26 ` David Laight
2020-08-24 13:28 ` Steven Rostedt
2020-08-24 13:42 ` Andy Shevchenko [this message]
2020-08-24 18:26 ` Steven Rostedt
2020-08-24 13:30 ` Steven Rostedt
2020-08-25 0:38 ` Nicolas Boichat
2020-08-26 1:39 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200824134201.GM1891694@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=David.Laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dianders@chromium.org \
--cc=drinkcat@chromium.org \
--cc=gpiccoli@canonical.com \
--cc=groeck@chromium.org \
--cc=huyue2@yulong.com \
--cc=keescook@chromium.org \
--cc=kerneldev@karsmulder.nl \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=yangtiezhu@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).