From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: openembedded-core@lists.openembedded.org,
Saul Wold <saul.wold@intel.com>
Subject: Re: [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
Date: Wed, 12 Sep 2012 14:48:37 +0100 [thread overview]
Message-ID: <1347457717.11710.12.camel@ted> (raw)
In-Reply-To: <CADkTA4OL98FtR_38BMn0H3zxVmvbJ08Yd7D3qcQX+Sei9kRLLg@mail.gmail.com>
On Wed, 2012-09-12 at 08:58 -0400, Bruce Ashfield wrote:
> On Wed, Sep 12, 2012 at 8:25 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Tue, 2012-09-11 at 09:07 -0700, Saul Wold wrote:
> >> On 09/11/2012 08:58 AM, Richard Purdie wrote:
> >> > On Tue, 2012-09-11 at 08:41 -0700, Saul Wold wrote:
> >> >> On 09/11/2012 08:39 AM, Bruce Ashfield wrote:
> >> >>> On 12-09-11 11:33 AM, Saul Wold wrote:
> >> >>>> On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
> >> >>>>> When x32 is the tuning for a x86 MACHINE, the kernel should also have
> >> >>>>> CONFIG_X86_X32=y.
> >> >>>>>
> >> >>>>> This can be accomplished by adding the x32 configuraion fragment to the
> >> >>>>> KERNEL_FEATURES when x32 is the tuning for a given machine.
> >> >>>>>
> >> >>>>> cc: Saul Wold <sgw@linux.intel.com>
> >> >>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> >> >>>>> ---
> >> >>>>> meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
> >> >>>>> meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
> >> >>>>> 2 files changed, 4 insertions(+), 2 deletions(-)
> >> >>>>>
> >> >>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
> >> >>>>> b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
> >> >>>>> index 4fd3845..156fb93 100644
> >> >>>>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
> >> >>>>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
> >> >>>>> @@ -10,7 +10,7 @@ KMETA = "meta"
> >> >>>>>
> >> >>>>> SRCREV_machine ?= "a35693b1287c0e50cdca33a1b95af0ff48b43cd0"
> >> >>>>> SRCREV_machine_qemuppc ?= "85a1190530cb5749f5f831670976b163438dc301"
> >> >>>>> -SRCREV_meta ?= "d9d5fc63d8b38705036e946ea77d971d95de11ad"
> >> >>>>> +SRCREV_meta ?= "e0374ce012e7e6fc8e5bb8b957addb0478950898"
> >> >>>>>
> >> >>>>> PR = "${INC_PR}.0"
> >> >>>>> PV = "${LINUX_VERSION}+git${SRCPV}"
> >> >>>>> @@ -27,3 +27,4 @@ KERNEL_FEATURES_append = " features/netfilter"
> >> >>>>> KERNEL_FEATURES_append = " features/taskstats"
> >> >>>>> KERNEL_FEATURES_append_qemux86 = " cfg/sound"
> >> >>>>> KERNEL_FEATURES_append_qemux86-64 = " cfg/sound"
> >> >>>>> +KERNEL_FEATURES_append_x32 = " cfg/x32"
> >> >>>>
> >> >>>> Scratch this bit and below, as I think I will use the other mechanism
> >> >>>> you talked about to go from a .conf file.
> >> >>>
> >> >>> Works for me. The meta change is staged and pushed out, I'll update this
> >> >>> patch to not have the KERNEL_FEATURES portion.
> >> >>>
> >> >> Thanks, see my other email to RP, since x32 is a feature that any x86-64
> >> >> machine might want to enable based on the DEFAULTTUNE it makes more
> >> >> sense to be in the machine config includes.
> >> >
> >> > No, it doesn't.
> >> >
> >> > What we need here is:
> >> >
> >> > -KERNEL_FEATURES_append = " features/taskstats"
> >> > +KERNEL_FEATURES_append = " features/taskstats ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32", "" ,d)}"
> >> >
> >> No, this would then only address the qemu machine, what about all the HW
> >> BSP that might want it, they would need to add this same line. If I add
> >> the KERNEL_FEATURES_append to the arch-ia32.inc, conditional on mx32,
> >> then any x86-64 BSP can just enable that TUNE, isn't that the point of
> >> the machine config tuning?
> >
> > It is the point, however, the key part of this you're ignoring is that
> > the kernel fragment management only happens for linux-yocto. Only the
> > linux-yocto recipe supports the KERNEL_FEATURES mechanism.
> >
> > The arch-ia32.inc file and any machine config *cannot* depend on
> > linux-yocto.
> >
> > So this glue belongs in linux-yocto. I agree is suboptimal for people
> > not using it but such is life, there isn't any generic mechanism we can
> > place this into.
>
> :)
>
> linux-yocto it is, I've respun the patches to include the TUNE_FEATURES check
> and pushed them to poky-contrib zedd/x32:
>
> 7aeb32 linux-yocto/3.4: add x32 configuration fragment
> d34a34c linux-yocto*: append to KERNEL_FEATURES instead of assigning
>
> I don't have a x32 build handy, but I assume Saul will take them for a spin.
>
> If you want a full resend of the series, shout and I'll git send-email them out.
I've merged this, thanks. I'm assuming Saul will test the end result.
Cheers,
Richard
prev parent reply other threads:[~2012-09-12 14:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 15:17 [PATCH 0/2] linux-yocto: x32 and features update Bruce Ashfield
2012-09-11 15:17 ` [PATCH 1/2] linux-yocto*: append to KERNEL_FEATURES instead of assigning Bruce Ashfield
2012-09-11 15:17 ` [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook Bruce Ashfield
2012-09-11 15:33 ` Saul Wold
2012-09-11 15:39 ` Bruce Ashfield
2012-09-11 15:41 ` Saul Wold
2012-09-11 15:58 ` Richard Purdie
2012-09-11 16:07 ` Saul Wold
2012-09-12 12:25 ` Richard Purdie
2012-09-12 12:58 ` Bruce Ashfield
2012-09-12 13:48 ` Richard Purdie [this message]
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=1347457717.11710.12.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=bruce.ashfield@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=saul.wold@intel.com \
/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.