All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Zanussi <tom.zanussi@intel.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 7/9] perf: add perf-scripting MACHINE_FEATURE
Date: Thu, 05 Jul 2012 08:54:27 -0500	[thread overview]
Message-ID: <1341496467.6761.25.camel@trz-ThinkPad-T420> (raw)
In-Reply-To: <1341495730.19821.14.camel@ted>

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





  reply	other threads:[~2012-07-05 14:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-03 18:10 [PATCH 0/9] perf: enable Perl and Python bindings, and perf TUI tom.zanussi
2012-07-03 18:10 ` [PATCH 1/9] perl: keep original libperl location tom.zanussi
2012-07-03 18:10 ` [PATCH 2/9] perl: add @STAGINGDIR@ for config.sh substitions tom.zanussi
2012-07-03 18:10 ` [PATCH 3/9] perl: use @STAGINGDIR@ in config.sh tom.zanussi
2012-07-03 18:10 ` [PATCH 4/9] perf: enable Python bindings tom.zanussi
2012-07-03 18:10 ` [PATCH 5/9] perf: enable Perl binding tom.zanussi
2012-07-03 18:10 ` [PATCH 6/9] perf: add libexec/perf-core and contents tom.zanussi
2012-07-03 18:10 ` [PATCH 7/9] perf: add perf-scripting MACHINE_FEATURE tom.zanussi
2012-07-04 14:02   ` Richard Purdie
2012-07-04 19:16     ` Tom Zanussi
2012-07-05 13:42       ` Richard Purdie
2012-07-05 13:54         ` Tom Zanussi [this message]
2012-07-03 18:10 ` [PATCH 8/9] qemumachines: make MACHINE_FEATURES append follow qemu.inc include tom.zanussi
2012-07-03 18:10 ` [PATCH 9/9] perf: add perf-tui MACHINE_FEATURE tom.zanussi
2012-07-05 17:56 ` [PATCH 0/9] perf: enable Perl and Python bindings, and perf TUI 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=1341496467.6761.25.camel@trz-ThinkPad-T420 \
    --to=tom.zanussi@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.