linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Alexei Budankov <abudankov@huawei.com>
Cc: Jiri Olsa <jolsa@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Michael Petlan <mpetlan@redhat.com>,
	Ian Rogers <irogers@google.com>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 2/3] perf tools: Allow to enable/disable events via control file
Date: Thu, 10 Dec 2020 15:27:43 -0300	[thread overview]
Message-ID: <20201210182743.GE195565@kernel.org> (raw)
In-Reply-To: <6214e1cd-e6a4-2a7a-160c-47212afdc190@huawei.com>

Em Thu, Dec 10, 2020 at 09:20:42PM +0300, Alexei Budankov escreveu:
> 
> On 10.12.2020 21:06, Jiri Olsa wrote:
> > On Thu, Dec 10, 2020 at 05:24:30PM +0100, Jiri Olsa wrote:
> >> On Mon, Dec 07, 2020 at 08:02:20PM +0300, Alexei Budankov wrote:
> >>> Hi,
> >>>
> >>> On 06.12.2020 20:05, Jiri Olsa wrote:
> >>>> Adding new control events to enable/disable specific event.
> >>>> The interface string for control file are:
> >>>>
> >>>>   'enable-<EVENT NAME>'
> >>>>   'disable-<EVENT NAME>'
> >>>
> >>> <SNIP>
> >>>
> >>>>
> >>>> when received the command, perf will scan the current evlist
> >>>> for <EVENT NAME> and if found it's enabled/disabled.
> >>>
> >>> <SNIP>
> >>>
> >>>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> >>>> index 70aff26612a9..05723227bebf 100644
> >>>> --- a/tools/perf/util/evlist.c
> >>>> +++ b/tools/perf/util/evlist.c
> >>>> @@ -1915,7 +1915,13 @@ static int evlist__ctlfd_recv(struct evlist *evlist, enum evlist_ctl_cmd *cmd,
> >>>>  		 bytes_read == data_size ? "" : c == '\n' ? "\\n" : "\\0");
> >>>>  
> >>>>  	if (bytes_read > 0) {
> >>>> -		if (!strncmp(cmd_data, EVLIST_CTL_CMD_ENABLE_TAG,
> >>>> +		if (!strncmp(cmd_data, EVLIST_CTL_CMD_ENABLE_EVSEL_TAG,
> >>>> +				    (sizeof(EVLIST_CTL_CMD_ENABLE_EVSEL_TAG)-1))) {
> >>>> +			*cmd = EVLIST_CTL_CMD_ENABLE_EVSEL;
> >>>> +		} else if (!strncmp(cmd_data, EVLIST_CTL_CMD_DISABLE_EVSEL_TAG,
> >>>> +				    (sizeof(EVLIST_CTL_CMD_DISABLE_EVSEL_TAG)-1))) {
> >>>> +			*cmd = EVLIST_CTL_CMD_DISABLE_EVSEL;
> >>>> +		} else if (!strncmp(cmd_data, EVLIST_CTL_CMD_ENABLE_TAG,
> >>>>  			     (sizeof(EVLIST_CTL_CMD_ENABLE_TAG)-1))) {
> >>>>  			*cmd = EVLIST_CTL_CMD_ENABLE;
> >>>>  		} else if (!strncmp(cmd_data, EVLIST_CTL_CMD_DISABLE_TAG,
> >>>> @@ -1952,6 +1958,8 @@ int evlist__ctlfd_process(struct evlist *evlist, enum evlist_ctl_cmd *cmd)
> >>>>  	char cmd_data[EVLIST_CTL_CMD_MAX_LEN];
> >>>>  	int ctlfd_pos = evlist->ctl_fd.pos;
> >>>>  	struct pollfd *entries = evlist->core.pollfd.entries;
> >>>> +	struct evsel *evsel;
> >>>> +	char *evsel_name;
> >>>>  
> >>>>  	if (!evlist__ctlfd_initialized(evlist) || !entries[ctlfd_pos].revents)
> >>>>  		return 0;
> >>>> @@ -1967,6 +1975,26 @@ int evlist__ctlfd_process(struct evlist *evlist, enum evlist_ctl_cmd *cmd)
> >>>>  			case EVLIST_CTL_CMD_DISABLE:
> >>>>  				evlist__disable(evlist);
> >>>>  				break;
> >>>> +			case EVLIST_CTL_CMD_ENABLE_EVSEL:
> >>>> +				evsel_name = cmd_data + sizeof(EVLIST_CTL_CMD_ENABLE_EVSEL_TAG) - 1;
> >>>
> >>> It makes sense to check that evsel_name still points
> >>> into cmd_data buffer after assigning to event name.
> >>
> >> right, will add that
> > 
> > actualy it's already checked in evlist__ctlfd_recv, evsel_name at
> > worst will be empty string so evlist__find_evsel_by_str will fail
> > 
> > I'll add '' around %s in the error output string:
> > 
> >   failed: can't find '%s' event
> > 
> > so it's obvious when it's empty
> 
> Looks good to me. Thanks!

I'm taking this as an Acked-by: you as per
Documentation/process/submitting-patches.rst:

<quoted>
Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
has at least reviewed the patch and has indicated acceptance.  Hence patch
mergers will sometimes manually convert an acker's "yep, looks good to me"
into an Acked-by: (but note that it is usually better to ask for an
explicit ack).
</>

Thanks,

- Arnaldo

  reply	other threads:[~2020-12-10 18:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-06 17:05 [PATCH 0/3] perf tools: Allow to enable/disable events via control pipe Jiri Olsa
2020-12-06 17:05 ` [PATCH 1/3] perf tools: Add evlist__disable_evsel/evlist__enable_evsel Jiri Olsa
2020-12-07 17:12   ` Alexei Budankov
2020-12-06 17:05 ` [PATCH 2/3] perf tools: Allow to enable/disable events via control file Jiri Olsa
2020-12-07 17:02   ` Alexei Budankov
2020-12-10 16:24     ` Jiri Olsa
2020-12-10 17:15       ` Arnaldo Carvalho de Melo
2020-12-10 17:19         ` Arnaldo Carvalho de Melo
2020-12-10 17:26           ` [BUG] jevents problem when cross building " Arnaldo Carvalho de Melo
2020-12-10 17:44             ` John Garry
2020-12-10 18:17               ` Arnaldo Carvalho de Melo
2020-12-10 18:27                 ` John Garry
2020-12-10 19:57                   ` John Garry
2020-12-16 11:41                     ` John Garry
2020-12-16 14:01                       ` Arnaldo Carvalho de Melo
2020-12-10 18:06       ` Jiri Olsa
2020-12-10 18:20         ` Alexei Budankov
2020-12-10 18:27           ` Arnaldo Carvalho de Melo [this message]
2020-12-10 18:32           ` Alexei Budankov
2020-12-06 17:05 ` [PATCH 3/3] perf tools: Allow to list " Jiri Olsa
2020-12-07 16:28   ` Arnaldo Carvalho de Melo
2020-12-07 17:09     ` Alexei Budankov
2020-12-07 19:53       ` Jiri Olsa
2020-12-07 19:51     ` Jiri Olsa
2020-12-07 13:25 ` [PATCH 0/3] perf tools: Allow to enable/disable events via control pipe Namhyung Kim
  -- strict thread matches above, loose matches on Subject: below --
2020-12-10 20:43 [PATCHv2 " Jiri Olsa
2020-12-10 20:43 ` [PATCH 2/3] perf tools: Allow to enable/disable events via control file Jiri Olsa
2020-12-15 15:14   ` Arnaldo Carvalho de Melo
2020-12-15 15:24     ` Jiri Olsa
2020-12-15 16:03       ` Arnaldo Carvalho de Melo
2020-12-15 16:18         ` Jiri Olsa
2020-12-15 16:27           ` Arnaldo Carvalho de Melo

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=20201210182743.GE195565@kernel.org \
    --to=acme@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=abudankov@huawei.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).