[OE-core] [PATCH] qemu.inc: Fix typo for KERNEL_FEATURES

[Bruce Ashfield]

On Fri, Sep 13, 2013 at 5:19 AM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> On Friday 13 September 2013 10:47:24 Martin Jansa wrote:
>> On Thu, Sep 12, 2013 at 11:42:54PM -0700, Saul Wold wrote:
>> > Thans to Bjorn Arnelid for finding this
>> >
>> > Cc: bjorn.arnelid at xdin.com
>> >
>> > [YOCTO #5173]
>> >
>> > Signed-off-by: Saul Wold <sgw at linux.intel.com>
>> > ---
>> >
>> >  meta/conf/machine/include/qemu.inc | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/meta/conf/machine/include/qemu.inc
>> > b/meta/conf/machine/include/qemu.inc index a78622d..8557777 100644
>> > --- a/meta/conf/machine/include/qemu.inc
>> > +++ b/meta/conf/machine/include/qemu.inc
>> > @@ -26,4 +26,4 @@ PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>> >
>> >  EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
>> >
>> >  # Provide the nfs server kernel module for all qemu images
>> >
>> > -KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
>> > +KERNEL_FEATURES_append_pn_linux-yocto = " features/nfsd/nfsd-enable.scc"
>>
>> Wait a minute, isn't _pn-foo correct override?
>
> It is. Bjorn and I discussed this on IRC already, this patch shouldn't be
> applied. He's switched back to the linux-yocto 3.2 kernel and I guess that
> feature is not available/working there, thus this change did fix his build
> failure as it effectively disabled the line. Perhaps we should fix the
> underlying bug instead? Bruce, any suggestions?

Outside of that there's no underlying bug or at least it is something
that is working
as it should ?

Linux yocto 3.2 didn't have that underlying feature, so combining the
master/1.5 qemu.inc
that is looking for that feature with the older tree will cause that
to warn and then
stop the build before some missing functionality is silently dropped.

To get around it, the KERNEL_FEATURES can be cleared (via a finalize handler
as an example), the same kernel feature can be provided by an update to that
kernel's meta-data, or as a userspace feature (but the feature
relative path will
be the issue). I have something for this in the 1.6 planning.

Anyway, rather than trying to be to fancy or complex and speed up 1.6 work, my
suggestion is to just clear the variable in a bbappend if working on
the 3.2 kernel
with this .inc

and again, by clear, I mean something like the following .. which I just happen
to have kicking around:

---------------------------------------------
# This handler has the ability to clear KERNEL_FEATURES, but should
# be used carefully since clearing KERNEL_FEATURES breaks the "contract"
# between layers and what the kernel provides
python kernfeatures_handler () {
    if not isinstance(e, bb.event.RecipeParsed):
        return

    kernfeatures_clear = e.data.getVar( 'KERNEL_FEATURES_CLEAR' )
    if kernfeatures_clear:
          e.data.setVar('KERNEL_FEATURES', "")

    kernfeatures_force = e.data.getVar( 'KERNEL_FEATURES_FORCE' )
    if kernfeatures_force:
          e.data.setVar('KERNEL_FEATURES', kernfeatures_force )
}
addhandler kernfeatures_handler
---------------------------------------------

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"