Patchwork [2/3] recipes-kernel: make perf a standalone package

From: Liang Li <liang.li@windriver.com>

perf has been coupled to the kernel packages via kernel.bbclass.
While maintaining the build of perf out of the kernel source tree
is desired the package coupling has proved to be awkward in
several situations such as:

  - when a kernel recipe doesn't want to build/provide perf
  - when licensing of dependencies would prohibit perf and hence
    the kernel from being built.

To solve some of these problems, this recipe is the extraction of
the linux-tools.inc provided perf compilation into a standalone
perf recipe that builds out of the kernel source, but is otherwise
independent.

No new functionality is provided above what the linux-tools.inc
variant provided, but the separate recipe provides baseline for
adding new functionality.

Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel.bbclass          |    7 +----
 meta/recipes-kernel/perf/perf_3.4.bb |   50 ++++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-kernel/perf/perf_3.4.bb

On 06/20/2012 07:31 AM, Bruce Ashfield wrote:
> From: Liang Li<liang.li@windriver.com>
>
> perf has been coupled to the kernel packages via kernel.bbclass.
> While maintaining the build of perf out of the kernel source tree
> is desired the package coupling has proved to be awkward in
> several situations such as:
>
>    - when a kernel recipe doesn't want to build/provide perf
>    - when licensing of dependencies would prohibit perf and hence
>      the kernel from being built.
>
> To solve some of these problems, this recipe is the extraction of
> the linux-tools.inc provided perf compilation into a standalone
> perf recipe that builds out of the kernel source, but is otherwise
> independent.
>
> No new functionality is provided above what the linux-tools.inc
> variant provided, but the separate recipe provides baseline for
> adding new functionality.
>
> Signed-off-by: Liang Li<liang.li@windriver.com>
> Signed-off-by: Bruce Ashfield<bruce.ashfield@windriver.com>
> ---
>   meta/classes/kernel.bbclass          |    7 +----
>   meta/recipes-kernel/perf/perf_3.4.bb |   50 ++++++++++++++++++++++++++++++++++
>   2 files changed, 51 insertions(+), 6 deletions(-)
>   create mode 100644 meta/recipes-kernel/perf/perf_3.4.bb
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 690de96..8d52d74 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -469,7 +469,7 @@ python populate_packages_prepend () {
>   	metapkg = "kernel-modules"
>   	d.setVar('ALLOW_EMPTY_' + metapkg, "1")
>   	d.setVar('FILES_' + metapkg, "")
> -	blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'perf-dbg', 'kernel-misc' ]
> +	blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'kernel-misc' ]
>   	for l in module_deps.values():
>   		for i in l:
>   			pkg = module_pattern % legitimize_package_name(re.match(module_regex, os.path.basename(i)).group(1))
> @@ -548,8 +548,3 @@ addtask deploy before do_build after do_install
>
>   EXPORT_FUNCTIONS do_deploy
>
> -# perf must be enabled in individual kernel recipes
> -PACKAGES =+ "perf-dbg perf"
> -FILES_perf = "${bindir}/* \
> -              ${libexecdir}"
> -FILES_perf-dbg = "${FILES_${PN}-dbg}"
> diff --git a/meta/recipes-kernel/perf/perf_3.4.bb b/meta/recipes-kernel/perf/perf_3.4.bb
> new file mode 100644
> index 0000000..997beb4
> --- /dev/null
> +++ b/meta/recipes-kernel/perf/perf_3.4.bb
> @@ -0,0 +1,50 @@
> +SUMMARY = "Performance analysis tools for Linux"
> +DESCRIPTION = "Performance counters for Linux are a new kernel-based \
> +subsystem that provide a framework for all things \
> +performance analysis. It covers hardware level \
> +(CPU/PMU, Performance Monitoring Unit) features \
> +and software features (software counters, tracepoints) \
> +as well."
> +
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> +
> +PR = "r0"
> +
> +BUILDPERF_libc-uclibc = "no"
> +
> +DEPENDS = "virtual/kernel \
> +           virtual/${MLPREFIX}libc \
> +           ${MLPREFIX}elfutils \
> +           ${MLPREFIX}binutils \
> +          "
> +RDEPENDS_${PN} += "elfutils perl python"
> +
Do you need to duplicated elfutils here?

And are both perl and python required on the runtime to use perf?

Can we package the perl and python bits independently?  Does it make 
sense to do that?  I have not used the kernel perf tools.

Sau!


> +PROVIDES = "virtual/perf"
> +
> +inherit kernel-arch
> +
> +S = "${STAGING_KERNEL_DIR}"
> +B = "${WORKDIR}/${BPN}-${PV}"
> +
> +EXTRA_OEMAKE = \
> +		'-C ${S}/tools/perf \
> +		O=${B} \
> +		CROSS_COMPILE=${TARGET_PREFIX} \
> +		ARCH=${ARCH} \
> +		CC="${CC}" \
> +		AR="${AR}" \
> +		prefix=/usr \
> +		NO_GTK2=1 NO_NEWT=1 NO_DWARF=1 \
> +		'
> +
> +do_compile() {
> +	oe_runmake all
> +}
> +
> +do_install() {
> +	oe_runmake DESTDIR=${D} install
> +}
> +
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
> +

On 12-06-20 11:00 AM, Saul Wold wrote:
> On 06/20/2012 07:31 AM, Bruce Ashfield wrote:
>> From: Liang Li<liang.li@windriver.com>
>>
>> perf has been coupled to the kernel packages via kernel.bbclass.
>> While maintaining the build of perf out of the kernel source tree
>> is desired the package coupling has proved to be awkward in
>> several situations such as:
>>
>> - when a kernel recipe doesn't want to build/provide perf
>> - when licensing of dependencies would prohibit perf and hence
>> the kernel from being built.
>>
>> To solve some of these problems, this recipe is the extraction of
>> the linux-tools.inc provided perf compilation into a standalone
>> perf recipe that builds out of the kernel source, but is otherwise
>> independent.
>>
>> No new functionality is provided above what the linux-tools.inc
>> variant provided, but the separate recipe provides baseline for
>> adding new functionality.
>>
>> Signed-off-by: Liang Li<liang.li@windriver.com>
>> Signed-off-by: Bruce Ashfield<bruce.ashfield@windriver.com>
>> ---
>> meta/classes/kernel.bbclass | 7 +----
>> meta/recipes-kernel/perf/perf_3.4.bb | 50
>> ++++++++++++++++++++++++++++++++++
>> 2 files changed, 51 insertions(+), 6 deletions(-)
>> create mode 100644 meta/recipes-kernel/perf/perf_3.4.bb
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 690de96..8d52d74 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -469,7 +469,7 @@ python populate_packages_prepend () {
>> metapkg = "kernel-modules"
>> d.setVar('ALLOW_EMPTY_' + metapkg, "1")
>> d.setVar('FILES_' + metapkg, "")
>> - blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base',
>> 'kernel-vmlinux', 'perf', 'perf-dbg', 'kernel-misc' ]
>> + blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base',
>> 'kernel-vmlinux', 'kernel-misc' ]
>> for l in module_deps.values():
>> for i in l:
>> pkg = module_pattern % legitimize_package_name(re.match(module_regex,
>> os.path.basename(i)).group(1))
>> @@ -548,8 +548,3 @@ addtask deploy before do_build after do_install
>>
>> EXPORT_FUNCTIONS do_deploy
>>
>> -# perf must be enabled in individual kernel recipes
>> -PACKAGES =+ "perf-dbg perf"
>> -FILES_perf = "${bindir}/* \
>> - ${libexecdir}"
>> -FILES_perf-dbg = "${FILES_${PN}-dbg}"
>> diff --git a/meta/recipes-kernel/perf/perf_3.4.bb
>> b/meta/recipes-kernel/perf/perf_3.4.bb
>> new file mode 100644
>> index 0000000..997beb4
>> --- /dev/null
>> +++ b/meta/recipes-kernel/perf/perf_3.4.bb
>> @@ -0,0 +1,50 @@
>> +SUMMARY = "Performance analysis tools for Linux"
>> +DESCRIPTION = "Performance counters for Linux are a new kernel-based \
>> +subsystem that provide a framework for all things \
>> +performance analysis. It covers hardware level \
>> +(CPU/PMU, Performance Monitoring Unit) features \
>> +and software features (software counters, tracepoints) \
>> +as well."
>> +
>> +LICENSE = "GPLv2"
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>> +
>> +PR = "r0"
>> +
>> +BUILDPERF_libc-uclibc = "no"
>> +
>> +DEPENDS = "virtual/kernel \
>> + virtual/${MLPREFIX}libc \
>> + ${MLPREFIX}elfutils \
>> + ${MLPREFIX}binutils \
>> + "
>> +RDEPENDS_${PN} += "elfutils perl python"
>> +
> Do you need to duplicated elfutils here?

AFAIK yes. Since perf uses them on the target.

>
> And are both perl and python required on the runtime to use perf?

Yes. With all the perf bindings, which is the plan, and one of the
main points in pulling this out from the kernel itself.

>
> Can we package the perl and python bits independently? Does it make
> sense to do that? I have not used the kernel perf tools.

That's down the road, TomZ is waiting for this to work on exactly
that.

Bruce

>
> Sau!
>
>
>> +PROVIDES = "virtual/perf"
>> +
>> +inherit kernel-arch
>> +
>> +S = "${STAGING_KERNEL_DIR}"
>> +B = "${WORKDIR}/${BPN}-${PV}"
>> +
>> +EXTRA_OEMAKE = \
>> + '-C ${S}/tools/perf \
>> + O=${B} \
>> + CROSS_COMPILE=${TARGET_PREFIX} \
>> + ARCH=${ARCH} \
>> + CC="${CC}" \
>> + AR="${AR}" \
>> + prefix=/usr \
>> + NO_GTK2=1 NO_NEWT=1 NO_DWARF=1 \
>> + '
>> +
>> +do_compile() {
>> + oe_runmake all
>> +}
>> +
>> +do_install() {
>> + oe_runmake DESTDIR=${D} install
>> +}
>> +
>> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> +
>

On Wednesday 20 June 2012 10:31:40 Bruce Ashfield wrote:
> From: Liang Li <liang.li@windriver.com>
>...
> +EXTRA_OEMAKE = \
> +		'-C ${S}/tools/perf \
> +		O=${B} \
> +		CROSS_COMPILE=${TARGET_PREFIX} \
> +		ARCH=${ARCH} \
> +		CC="${CC}" \
> +		AR="${AR}" \
> +		prefix=/usr \
> +		NO_GTK2=1 NO_NEWT=1 NO_DWARF=1 \

Coincidentally, I've just noticed that the current (kernel integrated) perf 
package can sometimes depend on gtk+/glib-2.0 or not depending on whether 
these are available when the kernel is built. Presumably NO_GTK2=1 above 
disables gtk+ support and thus would prevent this?

Cheers,
Paul

On 12-06-20 11:25 AM, Paul Eggleton wrote:
> On Wednesday 20 June 2012 10:31:40 Bruce Ashfield wrote:
>> From: Liang Li<liang.li@windriver.com>
>> ...
>> +EXTRA_OEMAKE = \
>> +		'-C ${S}/tools/perf \
>> +		O=${B} \
>> +		CROSS_COMPILE=${TARGET_PREFIX} \
>> +		ARCH=${ARCH} \
>> +		CC="${CC}" \
>> +		AR="${AR}" \
>> +		prefix=/usr \
>> +		NO_GTK2=1 NO_NEWT=1 NO_DWARF=1 \
>
> Coincidentally, I've just noticed that the current (kernel integrated) perf
> package can sometimes depend on gtk+/glib-2.0 or not depending on whether
> these are available when the kernel is built. Presumably NO_GTK2=1 above
> disables gtk+ support and thus would prevent this?

That was the plan. It hard disables it for now, and once we have
a more flexible package, we can add some optional dependencies and
features back into the equation.

Cheers,

Bruce

>
> Cheers,
> Paul
>