[Buildroot] [git commit] perf: add kernel version checks

[Buildroot] [git commit] perf: add kernel version checks

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=1727e89e9a6076ac81235a9377b749606e23d110
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

perf is only available since kernel 2.6.31, so if we can't find
tools/perf/Makefile, error out and tell the user about this.

perf without libelf can only be built since kernel 3.7, so error out
and tell the user about this if he's trying to build perf from a < 3.7
kernel without libelf.

Unfortunately, those tests can only be build-time checks as we either
need to know the real kernel version (i.e, using LINUX_VERSION would
not be correct as it can be a Git commit ID, or Git tag), or have
access to the kernel sources themselves. So we can't prevent those
invalid situations at the configuration, we can only nicely tell the
user at build time.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 package/perf/perf.mk |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/package/perf/perf.mk b/package/perf/perf.mk
index eed30a2..4356f5d 100644
--- a/package/perf/perf.mk
+++ b/package/perf/perf.mk
@@ -28,6 +28,18 @@ else
 endif
 
 define PERF_BUILD_CMDS
+	$(Q)if test ! -f $(LINUX_DIR)/tools/perf/Makefile ; then \
+		echo "Your kernel version is too old and does not have the perf tool." ; \
+		echo "At least kernel 2.6.31 must be used." ; \
+		exit 1 ; \
+	fi
+	$(Q)if test "$(BR2_PACKAGE_ELFUTILS)" = "" ; then \
+		if ! grep -q NO_LIBELF $(LINUX_DIR)/tools/perf/Makefile ; then \
+			echo "The perf tool in your kernel cannot be built without libelf." ; \
+			echo "Either upgrade your kernel to >= 3.7, or enable the elfutils package." ; \
+			exit 1 ; \
+		fi \
+	fi
 	$(MAKE) -C $(LINUX_DIR)/tools/perf \
 		$(PERF_MAKE_FLAGS) O=$(@D)
 endef

[Buildroot] [git commit] perf: add kernel version checks

[Arnout Vandecappelle]

On 07/01/13 21:40, Peter Korsgaard wrote:
> perf is only available since kernel 2.6.31, so if we can't find
> tools/perf/Makefile, error out and tell the user about this.
>
> perf without libelf can only be built since kernel 3.7, so error out
> and tell the user about this if he's trying to build perf from a<  3.7
> kernel without libelf.
>
> Unfortunately, those tests can only be build-time checks as we either
> need to know the real kernel version (i.e, using LINUX_VERSION would
> not be correct as it can be a Git commit ID, or Git tag), or have
> access to the kernel sources themselves. So we can't prevent those
> invalid situations at the configuration, we can only nicely tell the
> user at build time.
>
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> Signed-off-by: Peter Korsgaard<jacmet@sunsite.dk>

  There are a number of packages that would benefit from kernel version 
checks. For instance, the native driver implementations of igh-ethercat 
are specific for a certain kernel version. Would it be a good idea to 
make the kernel version user-configurable, and add a check for its 
correctness similar to the external toolchains?

  This would allow us to add a kernel build to the autobuilders, and thus 
autobuild the 5 packages that depend on BR2_LINUX_KERNEL.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [git commit] perf: add kernel version checks

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 08 Jan 2013 07:41:44 +0100, Arnout Vandecappelle wrote:

>   There are a number of packages that would benefit from kernel version 
> checks. For instance, the native driver implementations of igh-ethercat 
> are specific for a certain kernel version. Would it be a good idea to 
> make the kernel version user-configurable, and add a check for its 
> correctness similar to the external toolchains?

Huh? The kernel version is already user configurable, thanks to the
BR2_LINUX_KERNEL_3_7, BR2_LINUX_KERNEL_SAME_AS_HEADERS,
BR2_LINUX_KERNEL_CUSTOM_VERSION, BR2_LINUX_KERNEL_CUSTOM_TARBALL,
BR2_LINUX_KERNEL_CUSTOM_GIT configuration options.

The thing is that when the BR2_LINUX_KERNEL_CUSTOM_TARBALL or
BR2_LINUX_KERNEL_CUSTOM_GIT options are used, you don't know (at the
Kconfig level), the kernel version that will be used.

And I don't think we should ask the user to tell us, through a separate
option, what kernel version his/her Git tree actually contains.

Or maybe I'm missing what you're proposing here?

Regarding the kernel and the autobuilders, my plan was to modify the
autobuilders script to randomly enable the kernel build. The script of
course knows, per-architecture, of a known-working kernel defconfig
file that it would use in the Buildroot configuration.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit] perf: add kernel version checks

[Arnout Vandecappelle]

On 08/01/13 09:15, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Tue, 08 Jan 2013 07:41:44 +0100, Arnout Vandecappelle wrote:
>
>>    There are a number of packages that would benefit from kernel version
>> checks. For instance, the native driver implementations of igh-ethercat
>> are specific for a certain kernel version. Would it be a good idea to
>> make the kernel version user-configurable, and add a check for its
>> correctness similar to the external toolchains?
>
> Huh? The kernel version is already user configurable, thanks to the
> BR2_LINUX_KERNEL_3_7, BR2_LINUX_KERNEL_SAME_AS_HEADERS,
> BR2_LINUX_KERNEL_CUSTOM_VERSION, BR2_LINUX_KERNEL_CUSTOM_TARBALL,
> BR2_LINUX_KERNEL_CUSTOM_GIT configuration options.
>
> The thing is that when the BR2_LINUX_KERNEL_CUSTOM_TARBALL or
> BR2_LINUX_KERNEL_CUSTOM_GIT options are used, you don't know (at the
> Kconfig level), the kernel version that will be used.
>
> And I don't think we should ask the user to tell us, through a separate
> option, what kernel version his/her Git tree actually contains.
>
> Or maybe I'm missing what you're proposing here?

  I propose what you just said we shouldn't do: ask the user to tell us, 
through a separate option, what kernel version his/her git tree actually 
contains. Similar to the configuration of a preinstalled external toolchain.


> Regarding the kernel and the autobuilders, my plan was to modify the
> autobuilders script to randomly enable the kernel build. The script of
> course knows, per-architecture, of a known-working kernel defconfig
> file that it would use in the Buildroot configuration.

  It will be hard to find a kernel version that is supported by all of 
linux-fusion, igh-ethercat, owl-linux, lttng-modules and perf (and then 
I'm leaving out Xenomai and RTAI). For my all-package build, I just 
disabled those because it was too difficult to find a good one.


  Regards,
  Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [git commit] perf: add kernel version checks

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 08 Jan 2013 09:28:15 +0100, Arnout Vandecappelle wrote:

> > And I don't think we should ask the user to tell us, through a separate
> > option, what kernel version his/her Git tree actually contains.
> >
> > Or maybe I'm missing what you're proposing here?
> 
>   I propose what you just said we shouldn't do: ask the user to tell us, 
> through a separate option, what kernel version his/her git tree actually 
> contains. Similar to the configuration of a preinstalled external toolchain.

Wouldn't that be really annoying for the user? The external toolchain
thing is already a bit annoying (but it is made a bit more reasonable
in that the pre-existing profiles already know about this).

So, what you propose is that we have something like

config BR2_LINUX_KERNEL_REAL_VERSION
	string

And then, in Xenomai:

config BR2_..._XENOMAI
	depends on BR2_arm && BR2_LINUX_KERNEL_REAL_VERSION = "3.2.1"
	depends on BR2_powerpc && BR2_LINUX_KERNEL_REAL_VERSION = "x.y.z"

I understand the idea, but I really wonder if it's reasonable to ask
the user to specify which kernel version is being built...

> > Regarding the kernel and the autobuilders, my plan was to modify the
> > autobuilders script to randomly enable the kernel build. The script of
> > course knows, per-architecture, of a known-working kernel defconfig
> > file that it would use in the Buildroot configuration.
> 
>   It will be hard to find a kernel version that is supported by all of 
> linux-fusion, igh-ethercat, owl-linux, lttng-modules and perf (and then 
> I'm leaving out Xenomai and RTAI). For my all-package build, I just 
> disabled those because it was too difficult to find a good one.

Ah, yes, indeed. This can always be handled by some special knowledge
of autobuilder script, but it isn't entirely nice. That said, the
autobuilder script already encodes some similar knowledge like: let's
not build package FOO in toolchain BAR is selected, because I know the
gcc in toolchain BAR has a bug and generates an internal compiler error
when building package FOO.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com