Re: [GIT PULL] perf fixes

From: Jean Pihet
Date: Fri Sep 13 2013 - 13:15:41 EST


On 13 September 2013 11:45, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Jean Pihet <jean.pihet@xxxxxxxxxx> wrote:
>
>> Hi,
>>
>> On 13 September 2013 07:09, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>> >
>> > * David Ahern <dsahern@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/