linux-kernel - Re: [PATCH v2 01/10] perf tools: Integrating the CoreSight decoding library

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180118141423.GE18383@kernel.org>
Date:   Thu, 18 Jan 2018 11:14:23 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        namhyung@...nel.org, Adrian Hunter <adrian.hunter@...el.com>,
        Mike Leach <mike.leach@....com>, suzuki.poulosi@....com,
        Kim Phillips <kim.phillips@....com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 01/10] perf tools: Integrating the CoreSight decoding
 library

Em Thu, Jan 18, 2018 at 02:59:48PM +0100, Jiri Olsa escreveu:
> On Thu, Jan 18, 2018 at 10:41:39AM -0300, Arnaldo Carvalho de Melo wrote:
> > 	Shouldn't libopencsd be treated like libbabeltrace was before
> > the required version was widely available in distros?

> > 	I.e. these csets should have the rationale for that:

> > Enabling it once it became widely available:

> >    24787afbcd01 ("perf tools: Enable LIBBABELTRACE by default")

> > Disabling it because we would need to get things from tarballs/git
> > repos, build it in our machines, as requested by Ingo:

> >   6ab2b762befd ("perf build: Disable libbabeltrace check by default")
> 
> I think at that time we did not have a way to hide the check,
> now we have FEATURE_DISPLAY seprated so we can still check
> for it, but users won't be bothered with [ FAIL ] output

Ok, users won't be bothered with the fail output, but we tried hard to
get the build fast by having it only test for things that are widely
available, right? I.e. if we know something is not widely available then
we better not try to build with it and get faster builds, wasn't that
part of the rationale in the babeltrace case?

If one has to build from sources some library, then its not a problem to
have in the make command line a LIBOPENCSD=1 switch?

- Arnaldo