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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 13 Sep 2013 19:15:33 +0200
From:	Jean Pihet <jean.pihet@...aro.org>
To:	Ingo Molnar <mingo@...nel.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

On 13 September 2013 11:45, Ingo Molnar <mingo@...nel.org> wrote:
>
> * 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.
Ok!
I just sent a patch to feature-tests.mak for the newly added dwarf
unwinding feature ('perf tools: Check libunwind for availability of
dwarf parsing feature').

Thanks,
Jean

>
> 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/