All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf parse: Allow names to start with digits
Date: Mon, 4 Jul 2022 08:58:45 +0900	[thread overview]
Message-ID: <YsItNWBYfZ5UoUPf@codewreck.org> (raw)
In-Reply-To: <YsGduWiTvkM2/tHv@krava>

Jiri Olsa wrote on Sun, Jul 03, 2022 at 03:46:33PM +0200:
> > not sure if there'd be any other way of testing, there's nothing else in
> > 'perf list' that starts with a number.
> 
> maybe we could do it same way we did for fake pmu events like below

hmm, I'll have to defer to you on that honestly.

It looks good to me though and I've tested your diff (test succeeds even
with 9pnet module unloaded).

Just a note though, this makes test no longer checks the sys event
directories exist for all other tests in these arrays (test__events,
test__events_pmu and test__hybrid_events); if we have guarantees the
probes exist I believe at least a few should keep checking the format
path correctly.
It might be worth adding a check_format flag to test_event() and add a
new list that doesn't check formats just for 9p?

If you're ok with that I can resend this as three patches: my original
patch, a patch with your diff and test_event() keeping current
behaviour, and a last patch adding that last flag and testing 9p without
format check.

(and if you don't think it's worth checking probe existence same thing
but even simpler)
--
Dominique

  reply	other threads:[~2022-07-03 23:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-12  6:15 [PATCH] perf parse: Allow names to start with digits Dominique Martinet
2022-07-02  9:49 ` Dominique Martinet
2022-07-02 12:24   ` Arnaldo Carvalho de Melo
2022-07-02 15:48     ` Jiri Olsa
2022-07-02 23:51       ` Dominique Martinet
2022-07-03 13:46         ` Jiri Olsa
2022-07-03 23:58           ` Dominique Martinet [this message]
2022-07-04 11:25             ` Jiri Olsa
2022-10-10  5:38               ` Dominique Martinet
2022-10-10 14:05                 ` Jiri Olsa
2022-07-04 21:39 ` Ian Rogers

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=YsItNWBYfZ5UoUPf@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --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=olsajiri@gmail.com \
    --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.