Re: [RFC 00/79] perf tools: Initial libperf separation

[Jiri Olsa]

On Wed, Jul 24, 2019 at 07:42:50AM +0000, Song Liu wrote:
> Hi Jiri,
> 
> > On Jul 21, 2019, at 4:23 AM, Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> > 
> > hi,
> > we have long term goal to separate some of the perf functionality
> > into library. This patchset is initial effort on separating some
> > of the interface.
> > 
> > Currently only the basic counting interface is exported, it allows
> > to:
> >  - create cpu/threads maps
> >  - create evlist/evsel objects
> >  - add evsel objects into evlist
> >  - open/close evlist/evsel objects
> >  - enable/disable events
> >  - read evsel counts
> 
> Based on my understanding, evsel and evlist are abstractions in
> perf utilities. I think most other tools that use perf UAPIs are 
> not built based on these abstractions. I looked at a few internal

AFAICS some abstraction is needed to carry on the needed stuff
like mmaps, counts, group links, PMU details (type, cpus..)

> tools. Most of them just uses sys_perf_event_open() and struct 
> perf_event_attr. I am not sure whether these tools would adopt
> libperf, as libperf changes their existing concepts/abstractions.

well, besides that we wanted to do this separation for tools/* sake,
I think that once libperf shares more interface on sampling and pmu
events parsing, it will be considerable choice also for out of the
tree tools

> > 
> > The initial effort was to have total separation of the objects
> > from perf code, but it showed not to be a good way. The amount
> > of changed code was too big with high chance for regressions,
> > mainly because of the code embedding one of the above objects
> > statically.
> > 
> > We took the other approach of sharing the objects/struct details
> > within the perf and libperf code. This way we can keep perf
> > functionality without any major changes and the libperf users
> > are still separated from the object/struct details. We can move
> > to total libperf's objects separation gradually in future.
> 
> I found some duplicated logic between libperf and perf, for 
> example, perf_evlist__open() and evlist__open(). Do we plan to 
> merge them in the future? 

yea, as I wrote in the perf_evsel__open patch changelog:

  It's a simplified version of evsel__open without fallback
  stuff. We can try to merge it in the future to libperf,
  but it has many glitches.

some of the API can be shared right away, some needs more
changes and consideration

thanks,
jirka