Date:   Wed, 21 Mar 2018 15:52:37 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     "Jin, Yao" <yao.jin@...ux.intel.com>, 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] perf util: Display warning when perf report/annotate is
 missing some libs

Em Wed, Mar 21, 2018 at 05:04:46PM +0100, Jiri Olsa escreveu:
> On Wed, Mar 21, 2018 at 12:43:15PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Mar 21, 2018 at 12:40:35PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Wed, Mar 21, 2018 at 04:38:07PM +0100, Jiri Olsa escreveu:
> > > > On Wed, Mar 21, 2018 at 10:11:10AM +0800, Jin, Yao wrote:
> > > > > Hi Jiri,
> > > > > 
> > > > > I'm still thinking it's worth displaying the warning when perf missing some
> > > > > libraries.
> > > > > 
> > > > > Somebody just told me that perf didn't work well. While after some
> > > > > investigations, I found it's just missing some libraries when building the
> > > > > perf.
> > > > > 
> > > > > But I have spent some time on getting the root cause. If with this patch, it
> > > > > should be very easily to know that.

> > > > true.. Arnaldo, any feedback on this one?

> > > Lemme re-read the thread...

> > Well, how about we make it harder to build without key libraries? I.e.
> > if we detect that what we consider a core set of libraries isn't found
> > in the system, then we stop the build, warn about it and ask the user to
> > confirm that the build should proceed by passing some explicit
> > -DI_KNOW_WHAT_I_AM_DOING___PROCEED=doit

> hum, not sure we want to complicate the build even more than it
> is now :-\ and IMO it still won't help much in Jin's problem,
> if user forces the build anyway

Well, if a user _forces_ a build, not taking into consideration a
warning that _is_ emitted and _stops_ the build, about the functionality
it will lose by doing forcing the build, then comes back and complains
that that functionality is not present, then it becomes difficult to
help this user...  :-)

On the other hand, if the user forgets to install an important library,
the warning is emitted but the build proceeds, no explicit action was
performed, just a warning wasn't noticed, and the user complains, then
I'd say: "hey, are you sure library foo devel files were present when
you build it?", i.e. the support back and forth Jin is trying to avoid.

And for users that _saw_ the warning, _knew_ they _didn't_ want that
functionality, to be reminded while running, say 'perf report' that
something they _decided not to have_ isn't present, then that could be
annoying, no?

Lemme try another idea: what if we do something like gcc does and print
the features present when showing the version?

I.e.:

[acme@...et perf]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) 
[acme@...et perf]$ 

- Arnaldo

Powered by blists - more mailing lists