From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: James Clark <james.clark@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>,
linux-perf-users <linux-perf-users@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH] perf: Fix "Track with sched_switch" test by not printing warnings in quiet mode
Date: Mon, 17 Oct 2022 09:33:34 -0300 [thread overview]
Message-ID: <Y01Lnh5DqGUPuibf@kernel.org> (raw)
In-Reply-To: <912a4d0a-51b3-591b-8c8f-f078216d5b35@arm.com>
Em Fri, Oct 14, 2022 at 10:47:34AM +0100, James Clark escreveu:
> On 13/10/2022 17:57, Namhyung Kim wrote:
> > On Wed, Oct 12, 2022 at 10:12 AM James Clark <james.clark@arm.com> wrote:
> >> On 12/10/2022 17:50, Namhyung Kim wrote:
> >>> On Wed, Oct 12, 2022 at 4:13 AM James Clark <james.clark@arm.com> wrote:
> >>>>> The test already supplies -q to run in quiet mode, so extend quiet mode
> >>>>> to perf_stdio__warning() and also ui__warning() for consistency.
> >>>
> >>> I'm not sure if suppressing the warnings with -q is a good thing.
> >>> Maybe we need to separate warning/debug messages from the output.
> >>
> >> I don't see the issue with warnings being suppressed in quiet mode as
> >> long as errors are still printed. In other cases warnings have already
> >> been suppressed by quiet mode and this site is the odd one out.
> >>
> >> What use case are you thinking of where someone explicitly adds -q but
> >> wants to see non fatal warnings?
> >
> > I don't have any specific use case. If it's already suppressed in other
> > cases, I'm fine with it.
> >
>
> Actually I may have been mistaken. Seems like quiet is only used for
> "extra info" type messages rather than warnings. Although the commit
> message does say:
>
> The -q/--quiet option is to suppress any message. Sometimes users just
> want to see the numbers and it can be used for that case.
>
> With 'any' that I would take to include warnings as well. I could move
> warnings to stderr, but this has a much greater chance of breaking
> anyone's workflows that might be looking for warnings on stdout than
> removing warnings when -q is provided.
>
> Also if warnings are moved to stderr and quiet isn't used, there would
> be no way to suppress warnings in the TUI which might actually be a
> useful feature.
>
> So I'm still leaning towards the original change, if you are ok with
> that even though it's not done elsewhere?
Namhyung? I tend to agree with James.
- Arnaldo
next prev parent reply other threads:[~2022-10-17 12:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 11:10 [PATCH] perf: Fix "Track with sched_switch" test by not printing warnings in quiet mode James Clark
2022-10-12 11:13 ` James Clark
2022-10-12 16:50 ` Namhyung Kim
2022-10-12 17:12 ` James Clark
2022-10-13 16:57 ` Namhyung Kim
2022-10-14 9:47 ` James Clark
2022-10-17 12:33 ` Arnaldo Carvalho de Melo [this message]
2022-10-17 23:47 ` Namhyung Kim
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=Y01Lnh5DqGUPuibf@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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.