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 <[email protected]>wrote: > On Sat, Aug 31, 2013 at 10:12 PM, Chris Patterson <[email protected]> > 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" >
_______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
