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

[Chris Patterson]

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).

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?

Take care,
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20130831/20434d6d/attachment.html>