Patchwork [7/9] perf: add perf-scripting MACHINE_FEATURE

login
register
mail settings
Submitter Tom Zanussi
Date July 3, 2012, 6:10 p.m.
Message ID <0856ecabc55e047a8d4aeb67bf213a8d11cf385a.1341338051.git.tom.zanussi@intel.com>
Download mbox | patch
Permalink /patch/31119/
State New
Headers show

Comments

Tom Zanussi - July 3, 2012, 6:10 p.m.
From: Tom Zanussi <tom.zanussi@intel.com>

Add a new MACHINE_FEATURE named 'perf-scripting'.  Adding this into
any machine configuration will enable perf scripting on the target,
which will turn on all the language bindings currently aavailable in
perf (Perl and Python), if perf is included in an image.

If 'perf-scripting' isn't named as a feature (the default), all perf
language bindings will be disabled and unavailable.

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
---
 meta/recipes-kernel/perf/perf_3.4.bb |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
Richard Purdie - July 4, 2012, 2:02 p.m.
On Tue, 2012-07-03 at 13:10 -0500, tom.zanussi@intel.com wrote:
> From: Tom Zanussi <tom.zanussi@intel.com>
> 
> Add a new MACHINE_FEATURE named 'perf-scripting'.  Adding this into
> any machine configuration will enable perf scripting on the target,
> which will turn on all the language bindings currently aavailable in
> perf (Perl and Python), if perf is included in an image.
> 
> If 'perf-scripting' isn't named as a feature (the default), all perf
> language bindings will be disabled and unavailable.
> 
> Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> ---
>  meta/recipes-kernel/perf/perf_3.4.bb |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)

Does this make sense as a MACHINE specific feature? Wouldn't it make
sense done on a per architecture basis for example?

Cheers,

Richard
Tom Zanussi - July 4, 2012, 7:16 p.m.
On Wed, 2012-07-04 at 15:02 +0100, Richard Purdie wrote:
> On Tue, 2012-07-03 at 13:10 -0500, tom.zanussi@intel.com wrote:
> > From: Tom Zanussi <tom.zanussi@intel.com>
> > 
> > Add a new MACHINE_FEATURE named 'perf-scripting'.  Adding this into
> > any machine configuration will enable perf scripting on the target,
> > which will turn on all the language bindings currently aavailable in
> > perf (Perl and Python), if perf is included in an image.
> > 
> > If 'perf-scripting' isn't named as a feature (the default), all perf
> > language bindings will be disabled and unavailable.
> > 
> > Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> > ---
> >  meta/recipes-kernel/perf/perf_3.4.bb |   11 ++++++++---
> >  1 files changed, 8 insertions(+), 3 deletions(-)
> 
> Does this make sense as a MACHINE specific feature? Wouldn't it make
> sense done on a per architecture basis for example?
> 

To me it made sense to do it as a machine-specific feature e.g. although
scripting would probably be something that all x86-64-based machines
could be assumed to easily handle and would therefore probably want, for
x86 it might not always be so clear.  For example, the crownbay and
cedartrail machines might have the horsepower for scripting to make
sense on the target, while the n450 or some similarly underpowered Atom
machines, maybe not.

So, making it a per-machine feature would allow for that kind of
flexibility...

Tom

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - July 5, 2012, 1:42 p.m.
On Wed, 2012-07-04 at 14:16 -0500, Tom Zanussi wrote:
> On Wed, 2012-07-04 at 15:02 +0100, Richard Purdie wrote:
> > On Tue, 2012-07-03 at 13:10 -0500, tom.zanussi@intel.com wrote:
> > > From: Tom Zanussi <tom.zanussi@intel.com>
> > > 
> > > Add a new MACHINE_FEATURE named 'perf-scripting'.  Adding this into
> > > any machine configuration will enable perf scripting on the target,
> > > which will turn on all the language bindings currently aavailable in
> > > perf (Perl and Python), if perf is included in an image.
> > > 
> > > If 'perf-scripting' isn't named as a feature (the default), all perf
> > > language bindings will be disabled and unavailable.
> > > 
> > > Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> > > ---
> > >  meta/recipes-kernel/perf/perf_3.4.bb |   11 ++++++++---
> > >  1 files changed, 8 insertions(+), 3 deletions(-)
> > 
> > Does this make sense as a MACHINE specific feature? Wouldn't it make
> > sense done on a per architecture basis for example?
> > 
> 
> To me it made sense to do it as a machine-specific feature e.g. although
> scripting would probably be something that all x86-64-based machines
> could be assumed to easily handle and would therefore probably want, for
> x86 it might not always be so clear.  For example, the crownbay and
> cedartrail machines might have the horsepower for scripting to make
> sense on the target, while the n450 or some similarly underpowered Atom
> machines, maybe not.
> 
> So, making it a per-machine feature would allow for that kind of
> flexibility...

What is the implication if the machine lacks horsepower though? Isn't
this something you'd only hit when trying to use specific features?

I'm just not feeling this is the best way to make this decision.

Cheers,

Richard
Tom Zanussi - July 5, 2012, 1:54 p.m.
On Thu, 2012-07-05 at 14:42 +0100, Richard Purdie wrote:
> On Wed, 2012-07-04 at 14:16 -0500, Tom Zanussi wrote:
> > On Wed, 2012-07-04 at 15:02 +0100, Richard Purdie wrote:
> > > On Tue, 2012-07-03 at 13:10 -0500, tom.zanussi@intel.com wrote:
> > > > From: Tom Zanussi <tom.zanussi@intel.com>
> > > > 
> > > > Add a new MACHINE_FEATURE named 'perf-scripting'.  Adding this into
> > > > any machine configuration will enable perf scripting on the target,
> > > > which will turn on all the language bindings currently aavailable in
> > > > perf (Perl and Python), if perf is included in an image.
> > > > 
> > > > If 'perf-scripting' isn't named as a feature (the default), all perf
> > > > language bindings will be disabled and unavailable.
> > > > 
> > > > Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> > > > ---
> > > >  meta/recipes-kernel/perf/perf_3.4.bb |   11 ++++++++---
> > > >  1 files changed, 8 insertions(+), 3 deletions(-)
> > > 
> > > Does this make sense as a MACHINE specific feature? Wouldn't it make
> > > sense done on a per architecture basis for example?
> > > 
> > 
> > To me it made sense to do it as a machine-specific feature e.g. although
> > scripting would probably be something that all x86-64-based machines
> > could be assumed to easily handle and would therefore probably want, for
> > x86 it might not always be so clear.  For example, the crownbay and
> > cedartrail machines might have the horsepower for scripting to make
> > sense on the target, while the n450 or some similarly underpowered Atom
> > machines, maybe not.
> > 
> > So, making it a per-machine feature would allow for that kind of
> > flexibility...
> 
> What is the implication if the machine lacks horsepower though? Isn't
> this something you'd only hit when trying to use specific features?
> 

Nothing earth-shattering in that it won't break anything, it's just that
you're now dragging in the perl and python dependencies for no good
reason, since the scripting feature won't be too usable on the
underpowered machine.

> I'm just not feeling this is the best way to make this decision.
> 

Yeah, let me come up with something per architecture that also allows
individual machines to opt out...

Tom

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Patch

diff --git a/meta/recipes-kernel/perf/perf_3.4.bb b/meta/recipes-kernel/perf/perf_3.4.bb
index a1628bb..81121c1 100644
--- a/meta/recipes-kernel/perf/perf_3.4.bb
+++ b/meta/recipes-kernel/perf/perf_3.4.bb
@@ -19,7 +19,8 @@  DEPENDS = "virtual/kernel \
            ${MLPREFIX}binutils \
           "
 
-RDEPENDS_${PN} += "elfutils perl perl-modules python"
+SCRIPTING_RDEPENDS = "${@base_contains('MACHINE_FEATURES', 'perf-scripting', 'perl perl-modules python', '',d)}"
+RDEPENDS_${PN} += "elfutils ${SCRIPTING_RDEPENDS}"
 
 PROVIDES = "virtual/perf"
 
@@ -43,6 +44,8 @@  export PERL_ARCHLIB = "${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
 S = "${STAGING_KERNEL_DIR}"
 B = "${WORKDIR}/${BPN}-${PV}"
 
+SCRIPTING_DEFINES = "${@base_contains('MACHINE_FEATURES', 'perf-scripting', '', 'NO_LIBPERL=1 NO_LIBPYTHON=1',d)}"
+
 EXTRA_OEMAKE = \
 		'-C ${S}/tools/perf \
 		O=${B} \
@@ -51,7 +54,7 @@  EXTRA_OEMAKE = \
 		CC="${CC}" \
 		AR="${AR}" \
 		prefix=/usr \
-		NO_GTK2=1 NO_NEWT=1 NO_DWARF=1 \
+		NO_GTK2=1 NO_NEWT=1 NO_DWARF=1 ${SCRIPTING_DEFINES} \
 		'
 
 do_compile() {
@@ -60,7 +63,9 @@  do_compile() {
 
 do_install() {
 	oe_runmake DESTDIR=${D} install
-	oe_runmake DESTDIR=${D} install-python_ext
+	if [ "${@base_contains('MACHINE_FEATURES', 'perf-scripting', 1, 0, d)}" = "1" ]; then
+		oe_runmake DESTDIR=${D} install-python_ext
+	fi
 }
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"