public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH v2] sched/preempt: Tell about PREEMPT_DYNAMIC on kernel headers
Date: Thu, 17 Feb 2022 12:12:40 +0100	[thread overview]
Message-ID: <20220217111240.GA742892@lothringen> (raw)
In-Reply-To: <87mtj9nn3q.mognet@arm.com>

On Wed, Feb 02, 2022 at 06:24:09PM +0000, Valentin Schneider wrote:
> On 02/02/22 15:59, Frederic Weisbecker wrote:
> > Displaying "PREEMPT" on kernel headers when CONFIG_PREEMPT_DYNAMIC=y
> > can be misleading for anybody involved in remote debugging because it
> > is then not guaranteed that there is an actual preemption behaviour. It
> > depends on default Kconfig or boot defined choices.
> >
> > Therefore, tell about PREEMPT_DYNAMIC on static kernel headers and leave
> > the search for the actual preemption behaviour to browsing dmesg.
> >
> 
> Looks sensible. One small further cleanup nit below, otherwise:
> 
> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
[...]
> 
> I got suspicious of that PREEMPT_RT line, but it works because
> PREEMPT_BUILD and PREEMPT_RT are mutually exclusive. Nevertheless, could we
> clear out the ambiguity and make that into:
> 
> if   [ -n "$PREEMPT_RT" ] ;      then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT_RT";
> elif [ -n "$PREEMPT_DYNAMIC" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT_DYNAMIC";
> elif [ -n "$PREEMPT" ] ;         then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT";
> fi

Good point!

Here you go:

---
From: Frederic Weisbecker <frederic@kernel.org>
Date: Wed, 2 Feb 2022 15:59:54 +0100
Subject: [PATCH] sched/preempt: Tell about PREEMPT_DYNAMIC on kernel headers

Displaying "PREEMPT" on kernel headers when CONFIG_PREEMPT_DYNAMIC=y
can be misleading for anybody involved in remote debugging because it
is then not guaranteed that there is an actual preemption behaviour. It
depends on default Kconfig or boot defined choices.

Therefore, tell about PREEMPT_DYNAMIC on static kernel headers and leave
the search for the actual preemption behaviour to browsing dmesg.

Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 init/Makefile       |  3 ++-
 scripts/mkcompile_h | 17 ++++++++++++-----
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/init/Makefile b/init/Makefile
index 06326e304384..d82623d7fc8e 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -31,7 +31,8 @@ quiet_cmd_compile.h = CHK     $@
       cmd_compile.h = \
 	$(CONFIG_SHELL) $(srctree)/scripts/mkcompile_h $@	\
 	"$(UTS_MACHINE)" "$(CONFIG_SMP)" "$(CONFIG_PREEMPT_BUILD)"	\
-	"$(CONFIG_PREEMPT_RT)" "$(CONFIG_CC_VERSION_TEXT)" "$(LD)"
+	"$(CONFIG_PREEMPT_DYNAMIC)" "$(CONFIG_PREEMPT_RT)" \
+	"$(CONFIG_CC_VERSION_TEXT)" "$(LD)"
 
 include/generated/compile.h: FORCE
 	$(call cmd,compile.h)
diff --git a/scripts/mkcompile_h b/scripts/mkcompile_h
index 6a2a04d92f42..ca40a5258c87 100755
--- a/scripts/mkcompile_h
+++ b/scripts/mkcompile_h
@@ -5,9 +5,10 @@ TARGET=$1
 ARCH=$2
 SMP=$3
 PREEMPT=$4
-PREEMPT_RT=$5
-CC_VERSION="$6"
-LD=$7
+PREEMPT_DYNAMIC=$5
+PREEMPT_RT=$6
+CC_VERSION="$7"
+LD=$8
 
 # Do not expand names
 set -f
@@ -41,8 +42,14 @@ fi
 UTS_VERSION="#$VERSION"
 CONFIG_FLAGS=""
 if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi
-if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi
-if [ -n "$PREEMPT_RT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT_RT"; fi
+
+if [ -n "$PREEMPT_RT" ] ; then
+	CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT_RT"
+elif [ -n "$PREEMPT_DYNAMIC" ] ; then
+	CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT_DYNAMIC"
+elif [ -n "$PREEMPT" ] ; then
+	CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"
+fi
 
 # Truncate to maximum length
 UTS_LEN=64
-- 
2.25.1


  reply	other threads:[~2022-02-17 11:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02 14:59 [PATCH] sched/preempt: Tell about PREEMPT_DYNAMIC on kernel headers Frederic Weisbecker
2022-02-02 18:24 ` Valentin Schneider
2022-02-17 11:12   ` Frederic Weisbecker [this message]
2022-03-10  8:53     ` [PATCH v2] " Peter Zijlstra
2022-03-11 14:40     ` [tip: sched/core] " tip-bot2 for Frederic Weisbecker

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=20220217111240.GA742892@lothringen \
    --to=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=valentin.schneider@arm.com \
    /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