[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160209090236.GA20503@lst.de>
Date: Tue, 9 Feb 2016 10:02:36 +0100
From: Torsten Duwe <duwe@....de>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Petr Mladek <pmladek@...e.com>,
Michael Ellerman <mpe@...erman.id.au>,
Jiri Kosina <jkosina@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
Jessica Yu <jeyu@...hat.com>, linuxppc-dev@...ts.ozlabs.org,
linux-kernel@...r.kernel.org, live-patching@...r.kernel.org
Subject: Re: [PATCH v7 04/10] ppc64 ftrace_with_regs configuration variables
On Mon, Feb 08, 2016 at 10:49:28AM -0500, Steven Rostedt wrote:
> On Mon, 8 Feb 2016 16:23:06 +0100
> Petr Mladek <pmladek@...e.com> wrote:
>
> > >From 2b0fcb678d7720d03f9c9f233b61ed9ed4d420b3 Mon Sep 17 00:00:00 2001
> > From: Petr Mladek <pmladek@...e.com>
> > Date: Mon, 8 Feb 2016 16:03:03 +0100
> > Subject: [PATCH] ftrace: Allow to explicitly disable the build of the dynamic
> > ftrace with regs
> >
> > This patch allows to explicitly disable
> > CONFIG_DYNAMIC_FTRACE_WITH_REGS. We will need to do so on
> > PPC with a broken gcc. This situation will be detected at
> > buildtime and could not be handled by Kbuild automatically.
>
> Wait. Can it be detected at build time? That is, does it cause a build
Yes, I wrote a test to detect it at build time. It is similar to "asm goto"
and part of the v7 patch set.
> error? If so, then you can have Kbuild automatically detect this and
> set the proper value. We do this with 'asm goto'. There's tricks in the
> build system that can change the configs based on if a compiler is
> broken or not.
Please clarify. All I could find is Makefile magic that does it. AFAICS
This runs _after_ Kconfig.
But what I'd like to see is to offer the user the full choice, where possible,
e.g.
Kernel Tracing ...
0) none
1) static FTRACE
2) DYNAMIC_FTRACE
3) DYNAMIC_FTRACE_WITH_REGS
Can such a test be used to simply reduce these options?
With Petr's patch, it comes quite close to the above, and if you select "3"
and your compiler is broken, compilation will fail. For "2", it will just do
the right thing ( fall back to plain "-pg" ).
Without Petr's patch you have *no* choice between "2" and "3".
(That's what I'd call a bug :)
So, the question is, can such a test be used to provide _input_ to
"make config" ? I can see the "env=" mechanism, but it seems not to be used
very heavily. That would then be a prerequisite to all "make *config".
Even if it can provide this input, you can still not choose between 2 and 3
where both are available.
Torsten
Powered by blists - more mailing lists