linux-kernel - Re: [GIT PULL] perf fixes

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]

Date:	Fri, 13 Sep 2013 11:45:55 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Jean Pihet <jean.pihet@...aro.org>
Cc:	David Ahern <dsahern@...il.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] perf fixes


* Jean Pihet <jean.pihet@...aro.org> wrote:

> Hi,
> 
> On 13 September 2013 07:09, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > * David Ahern <dsahern@...il.com> wrote:
> >
> >> > By default a simple 'make' should build perf to the maximum extent
> >> > possible, with no other input required from the user - with warnings
> >> > displayed as package install suggestions.
> >>
> >> By default there is no config. Autoprobing generates a first one or a
> >> user can specify a defconfig.
> >
> > This could work if there's not two but three states for individual
> > features:
> >
> >   - autoprobe
> >   - on
> >   - off
> >
> > and if autoprobe, if a system feature has been probed successfully,
> > automatically turned 'autoprobe' entries into 'on'.
> >
> > That would give us the best of all worlds - autodetection, configurability
> > and caching:
> >
> >  - initial user types 'make' and gets a .config that has almost all
> >    entries 'on', a few 'autoprobe'.
> >
> >  - once the user installs a dependency, the corresponding .config entry
> >    turns into 'on'.
> >
> >  - the regular user or developers would have libraries that turn all
> >    entries in the .config to 'on'.
> >
> >  - if a user is genuinely uninterested in a feature, he can mark it 'off',
> >    which would then stay off permanently. This could also be used by
> >    embedded/specialized builds.
> >
> >  - other specialized users, like distro builds, could use a .config with
> >    all entries 'on' and could enforce the presence of all dependencies for
> >    a successful build. [We could add 'make allyesconfig' to help that.]
> 
> Is there a way to detect the presence of a dependency and _also_ check 
> its version? Some new features are depending on a recent version of a 
> library, e.g. dwarf unwinding depends on libunwind >= 1.1 (cf. 
> http://www.spinics.net/lists/kernel/msg1598951.html).

Yeah, see the testcases in tools/perf/config/feature-tests.mak, they 
typically include the latest library API usages, which will fail on older 
versions.

That kind of 'does it actually work?' test is a lot more robust than 
explicit version checks, and combined with caching it should be fast and 
parallelizable as well. (One of the problems of the current simple 
implementation of the feature tests is that they are 20 serial tests with 
no parallelization.)

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/