From: Saul Wold <saul.wold@intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Cc: liang.li@windriver.com
Subject: Re: [PATCH 2/3] recipes-kernel: make perf a standalone package
Date: Wed, 20 Jun 2012 08:00:13 -0700 [thread overview]
Message-ID: <4FE1E57D.8050803@intel.com> (raw)
In-Reply-To: <6e8878c5f3598b60d364e2656af74e9f712770ca.1340201997.git.bruce.ashfield@windriver.com>
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}"
> +
next prev parent reply other threads:[~2012-06-20 15:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 14:31 [v2 PATCH 0/3] perf: make perf a standlone recipe Bruce Ashfield
2012-06-20 14:31 ` [PATCH 1/3] kernel: save $kerndir/tools and $kerndir/lib from pruning Bruce Ashfield
2012-06-20 14:31 ` [PATCH 2/3] recipes-kernel: make perf a standalone package Bruce Ashfield
2012-06-20 15:00 ` Saul Wold [this message]
2012-06-20 15:02 ` Bruce Ashfield
2012-06-20 15:25 ` Paul Eggleton
2012-06-20 15:27 ` Bruce Ashfield
2012-06-20 14:31 ` [PATCH 3/3] recipes-kernel: remove linux-tools.inc Bruce Ashfield
2012-06-22 18:00 ` [v2 PATCH 0/3] perf: make perf a standlone recipe Saul Wold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE1E57D.8050803@intel.com \
--to=saul.wold@intel.com \
--cc=liang.li@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox