[meta-virtualization] [PATCH 1/4] linux-yocto: add kernel fragment and scc for xen dom0 kernel support.

[Chris Patterson]

I went back and double checked - you are right - last fragment wins as you
expected. I typo'd something in my test :)  Thanks for the clarification,
that makes more sense to me now.


On Sun, Sep 1, 2013 at 12:01 AM, Bruce Ashfield <bruce.ashfield at gmail.com>wrote:

> On Sat, Aug 31, 2013 at 10:12 PM, Chris Patterson <cjp256 at gmail.com>
> wrote:
> > That'd be great.  There are a couple areas that could perhaps use some
> work,
> > as the fragment is a little excessive in some of the options and/or
> could be
> > broken up a little better, if desired.  On this topic, I have a couple
> > questions that would help steer me in the right direction in the future:
> >
> > 1) One thing that's not immediately clear for me is the question of how
> to
> > best handle a case where a CONFIG_XXX option may in one instance, be
> > desirable to be built in - vs being a module in another?  Doing a quick
> test
> > seems to imply the first defined instance is the one used, but I'm not
> sure
> > if there are any well defined rules for conflict resolution.  The reason
> I'm
> > asking is there are CONFIG_XXX=y instances in this config - some of which
> > need to be built in, some required, and some just *preferably* built in
> for
> > various use cases. Specifically CONFIG_XEN_PCIDEV_BACKEND=y provides some
> > useful functionality before a module could otherwise be loaded (prevent a
> > pci device from being owned by a linux driver).
>
> It should be last through the gate that wins, which gives the fragment that
> includes another one a chance to tweak and override what it doesn't like.
>
> If you were really seeing first one being set, then something has broken
> and
> I'll hunt it down, I never assume that something hasn't managed to break
> itself, but it should still be behaving as it has before.
>
> What you may have seen is that KERNEL_FEATURES and .scc files on a
> SRC_URI are applied in a particular order. .scc files and then
> KERNEL_FEATURES,
> so if you want to override a feature, you need to do it with another
> features.
>
> So in your case, you can have that base fragment sets the requirements as
> built in, that's a good start. You could then have a secondary fragment
> which
> sets the preferable options, and more fragments that had completely
> optional
> values. Leaving the recipes and higher level fragments to chose the mix
> they
> want.
>
> Alternatively, you can set them all in the single fragment like it is, and
> then
> the including feature can always override, or from recipe space additional
> features be triggered override the values.
>
> >
> > 2) The other thing I am curious about is how to negotiate the inclusion
> of a
> > KERNEL_FEATURES which has a number of built-in bits.  The approach used
> by
> > kvm is to effectively always enable the fragment if one is including
> > meta-virtualization.  This in and of itself isn't really polluting the
> > target image for those that don't want KVM, because they likely simply
> don't
> > include the built kvm modules (ignoring CONFIG_TUN=y).  However, when you
> > have the =y cases, the user of the layer doesn't have a choice without
> going
> > through and commenting out the KERNEL_FEATURES_append...?  This was the
> > reasoning I took for choosing the base_contains() functionality instead
> of
> > just including it like the other bits (ebtables, vswitch, etc.).  Is the
> > goal for the layer's linux-yocto bbappend to support a "generic" kernel
> (by
> > default) to support all of its packages/images?
>
> An excellent point .. and yes, a layer shouldn't really be setting
> values like this
> unless it was single purpose. If we have Xen and KVM both active and
> available
> via meta-virt, then we really don't want that.
>
> I'd convert KVM to trigger via a IMAGE or DISTRO feature as well, just as
> you've
> done with your fragments.
>
> Cheers,
>
> Bruce
>
> >
> > Take care,
> > -Chris
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20130901/2024f280/attachment.html>