[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180305150409.GA22849@kernel.org>
Date: Mon, 5 Mar 2018 12:04:09 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
linux-kernel@...r.kernel.org, namhyung@...nel.org,
wangnan0@...wei.com, ak@...ux.intel.com
Subject: Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event()
interface
Em Mon, Mar 05, 2018 at 09:50:10AM -0500, Liang, Kan escreveu:
>
>
> On 3/5/2018 8:46 AM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Mar 05, 2018 at 10:03:39AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > I'm doing this, the argument is 'bool', so the value should be false or
> > > true, even '0' being way shorter...
> > While doing that I wonder why is that we can't do it without those
> > explicit start/end variables in all the call sites and passing
> > overwrite, start and end as parameters...
> > Can't we just add 'overwrite, 'start' and 'end' to struct perf_mmap,
> > then have perf_mmap__read_init() with just 'md' and 'overwrite' as
> > parameters, initialize md->{start,end} and set md->overwrite to the
> > 'overwrite' parameter in 'perf_mmap__read_init()' and then use just
> > md as parameters for both perf_mmap__read_event() and
> > perf_mmap__consume()?
> I don't see any reason we cannot do this.
> I will do some test. If it works well, I will submit the follow-up patch to
> clean up the interface.
Thanks a lot! The less boilerplate we have in such functions, making
them easier to use for new people contributing to tools/perf/, the
better.
- Arnaldo
Powered by blists - more mailing lists