[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dd674533-4d9c-4298-b6c3-9196b270f68b@arm.com>
Date: Fri, 11 Oct 2024 10:40:27 +0100
From: Leo Yan <leo.yan@....com>
To: Adrian Hunter <adrian.hunter@...el.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>,
James Clark <james.clark@...aro.org>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/5] libperf cpumap: Correct reference count for
perf_cpu_map__merge()
On 10/11/24 10:34, Leo Yan wrote:
>> The 2 non-test uses of perf_cpu_map__merge both do:
>>
>> a = perf_cpu_map__merge(a, b);
>>
>> so another way to make the API less misleading would be
>> to introduce:
>>
>> err = perf_cpu_map__merge_in(&a, b);
>>
>> where:
>>
>> int perf_cpu_map__merge_in(struct perf_cpu_map **orig, struct perf_cpu_map
>> *other)
>> {
>> struct perf_cpu_map *result = perf_cpu_map__merge(*orig, other);
>>
>> if (!result)
>> return -ENOMEM;
>>
>> *orig = result;
>> return 0;
>> }
>>
>> without any changes to perf_cpu_map__merge().
>
> Just wandering why we cannot do the same thing for the perf_cpu_map__merge()
> function?
>
> int perf_cpu_map__merge_in(struct perf_cpu_map **orig,
> struct perf_cpu_map *other)
Sorry for typo and spamming. The above suggested definition is for
perf_cpu_map__merge().
> This can allow us to avoid any confusion in the first place. And we don't need
> to maintain two functions for the same thing.
>
> Thanks,
> Leo
>
>
Powered by blists - more mailing lists