[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2334220f-22b5-c7eb-f9ec-ee70f41e96cb@linux.intel.com>
Date: Wed, 2 Sep 2020 16:16:28 +0800
From: "Jin, Yao" <yao.jin@...ux.intel.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: acme@...nel.org, jolsa@...nel.org, peterz@...radead.org,
mingo@...hat.com, alexander.shishkin@...ux.intel.com,
Linux-kernel@...r.kernel.org, ak@...ux.intel.com,
kan.liang@...el.com, yao.jin@...el.com
Subject: Re: [PATCH v4 1/7] perf util: Create streams
Hi Jiri,
On 9/2/2020 4:09 AM, Jiri Olsa wrote:
> On Tue, Sep 01, 2020 at 10:26:25AM +0800, Jin, Yao wrote:
>> Hi Jiri,
>>
>> On 8/31/2020 9:56 PM, Jiri Olsa wrote:
>>> On Tue, Aug 25, 2020 at 07:35:07AM +0800, Jin Yao wrote:
>>>
>>> SNIP
>>>
>>>> + int nr_streams_max,
>>>> + enum stream_type type)
>>>> +{
>>>> + struct evsel_streams *es;
>>>> + int nr_evsel = evlist->core.nr_entries, ret = -1;
>>>> +
>>>> + es = create_evsel_streams(nr_evsel, nr_streams_max);
>>>> + if (!es)
>>>> + return NULL;
>>>> +
>>>> + if (type == STREAM_CALLCHAIN)
>>>> + ret = evlist_init_callchain_streams(evlist, es, nr_evsel);
>>>> +
>>>> + if (ret) {
>>>> + free_evsel_streams(es, nr_evsel);
>>>> + return NULL;
>>>> + }
>>>> +
>>>> + return es;
>>>> +}
>>>> diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
>>>> new file mode 100644
>>>> index 000000000000..a8a0172b4d13
>>>> --- /dev/null
>>>> +++ b/tools/perf/util/stream.h
>>>> @@ -0,0 +1,30 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>> +#ifndef __PERF_STREAM_H
>>>> +#define __PERF_STREAM_H
>>>> +
>>>> +#include "callchain.h"
>>>> +
>>>> +enum stream_type {
>>>> + STREAM_NONE = 0,
>>>> + STREAM_CALLCHAIN
>>>
>>> do you plan to add more types?
>>>
>>> jirka
>>>
>>
>> Thanks for looking at this patch series.
>>
>> So far, no more types in plan. :)
>
> I was wondering what's the enum for then, it could
> be hardcoded and ease up the code maybe? but it's
> jus a thought, I don't follow the change deeply
>
> jirka
>
Hmm, I've ever thought to add a new type such as stream_block in the future. But in order to let the
patchset be simple and clear, I'm OK to remove this enum.
Thanks
Jin Yao
Powered by blists - more mailing lists