All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: kernel test robot <lkp@intel.com>,
	chongjiapeng <jiapeng.chong@linux.alibaba.com>,
	llvm@lists.linux.dev, kbuild-all@lists.01.org,
	linux-kernel@vger.kernel.org
Subject: Re: kernel/trace/ftrace.c:7157:20: error: unused function 'ftrace_startup_enable'
Date: Mon, 14 Feb 2022 13:57:39 -0500	[thread overview]
Message-ID: <20220214135739.60b2149e@gandalf.local.home> (raw)
In-Reply-To: <Ygp64CsyyKyRykqE@dev-arch.archlinux-ax161>

On Mon, 14 Feb 2022 08:53:04 -0700
Nathan Chancellor <nathan@kernel.org> wrote:

> I will be honest, I don't know why the robot flagged 172f7ba9772c as the
> commit that introduced this warning but it seems legitimate if
> CONFIG_DYNAMIC_FTRACE is not enabled, since ftrace_startup_enable() is
> only ever used within an '#ifdef CONFIG_DYNAMIC_FTRACE' block so I guess
> the stub is unnecessary?

I'm all fine for clean up patches, but I don't like "new warning" message
reports for things that use to be OK, but now are a warning.

In other words, if a bot updates its warnings, it should do a full pass of
the kernel before it starts on new commits, to flag all existing warnings
as OK (but possibly work for someone to clean up), but should not ever send
as a new warning message to the authors.

So, I'm going to ignore this. If someone wants to send me a clean up patch,
I'll test it and take it, but I do not have the time to clean up new
warnings that use to be OK unless they uncovered a real bug.

-- Steve

WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt@goodmis.org>
To: kbuild-all@lists.01.org
Subject: Re: kernel/trace/ftrace.c:7157:20: error: unused function 'ftrace_startup_enable'
Date: Mon, 14 Feb 2022 13:57:39 -0500	[thread overview]
Message-ID: <20220214135739.60b2149e@gandalf.local.home> (raw)
In-Reply-To: <Ygp64CsyyKyRykqE@dev-arch.archlinux-ax161>

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Mon, 14 Feb 2022 08:53:04 -0700
Nathan Chancellor <nathan@kernel.org> wrote:

> I will be honest, I don't know why the robot flagged 172f7ba9772c as the
> commit that introduced this warning but it seems legitimate if
> CONFIG_DYNAMIC_FTRACE is not enabled, since ftrace_startup_enable() is
> only ever used within an '#ifdef CONFIG_DYNAMIC_FTRACE' block so I guess
> the stub is unnecessary?

I'm all fine for clean up patches, but I don't like "new warning" message
reports for things that use to be OK, but now are a warning.

In other words, if a bot updates its warnings, it should do a full pass of
the kernel before it starts on new commits, to flag all existing warnings
as OK (but possibly work for someone to clean up), but should not ever send
as a new warning message to the authors.

So, I'm going to ignore this. If someone wants to send me a clean up patch,
I'll test it and take it, but I do not have the time to clean up new
warnings that use to be OK unless they uncovered a real bug.

-- Steve

  parent reply	other threads:[~2022-02-14 18:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-13 13:03 kernel/trace/ftrace.c:7157:20: error: unused function 'ftrace_startup_enable' kernel test robot
2022-02-13 13:03 ` kernel test robot
2022-02-14 15:20 ` Steven Rostedt
2022-02-14 15:20   ` Steven Rostedt
2022-02-14 15:53   ` Nathan Chancellor
2022-02-14 15:53     ` Nathan Chancellor
2022-02-14 16:28     ` Masahiro Yamada
2022-02-14 16:28       ` Masahiro Yamada
2022-02-14 17:00       ` Nathan Chancellor
2022-02-14 17:00         ` Nathan Chancellor
2022-02-14 18:57     ` Steven Rostedt [this message]
2022-02-14 18:57       ` 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=20220214135739.60b2149e@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=jiapeng.chong@linux.alibaba.com \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.