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

[Bruce Ashfield]

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"