[OE-core] [PATCH] linux-yocto-custom: Clarify defconfig usage

[Bruce Ashfield]

On Wed, Oct 3, 2012 at 10:07 AM, Andrea Adami <andrea.adami at gmail.com> wrote:
> On Wed, Oct 3, 2012 at 2:33 PM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
>> On Wed, Oct 3, 2012 at 8:10 AM, Andrea Adami <andrea.adami at gmail.com> wrote:
>>> On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield
>>> <bruce.ashfield at windriver.com> wrote:
>>>> On 12-10-03 12:36 AM, Darren Hart wrote:
>>>>>
>>>>> It is necessary to supply file://defconfig to the SRC_URI when using
>>>>> a defconfig (it is not implicitly understood as the commentary might
>>>>> currently suggest).
>>>>
>>>>
>>>> Acked-by: Bruce Ashfield <bruce.ashfield at windriver.com>
>>>>
>>>>
>>>>>
>>>>> Signed-off-by: Darren Hart<dvhart at linux.intel.com>
>>>>> CC: Bruce Ashfield<bruce.ashfield at windriver.com>
>>>>> ---
>>>>>   meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 3 ++-
>>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>>>> b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>>>> index 1f0b3a2..4115d2f 100644
>>>>> --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>>>> +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
>>>>> @@ -13,7 +13,8 @@
>>>>>   #
>>>>>   #   You must also provide a Linux kernel configuration. The most direct
>>>>>   #   method is to copy your .config to files/defconfig in your layer,
>>>>> -#   in the same directory as the bbappend.
>>>>> +#   in the same directory as the bbappend and add file://defconfig to
>>>>> +#   your SRC_URI.
>>>>>   #
>>>>>   #   To use the yocto kernel tooling to generate a BSP configuration
>>>>>   #   using modular configuration fragments, see the yocto-bsp and
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>> Great, this example can be very useful to create custom kernel recipes.
>>>
>>> Just one thing, the comments on the top suggest to set
>>> #     COMPATIBLE_MACHINE_yourmachine = "yourmachine"
>>>
>>> but at the end there is
>>> COMPATIBLE_MACHINE = "(^$)"
>>>
>>> Now, the latter form is what I'm used to see.
>>>
>>> Which kind of advantages using COMPATIBLE_MACHINE_yourmachine ? In
>>> that way you don't mask the recipe for other machines...so I don't see
>>> the purpose and I think should be discouraged. Thus, I'd amend the
>>> example in the comment.
>>
>> I wouldn't call it exactly masking with that syntax. Other machines
>> can still set
>> their compatibility explicitly with their own machine specific
>> override, which is
>> how linux-yocto + linux-yocto-bsp + meta-$semi have been put together for
>> quite some time.
>
> As long as the layer containing the -custom kernel recipe is not used
> by other machines all is fine.

That's typically what we do around here, the BSP layer has a bbappend
that sets the compatibility. So wouldn't be reused by any other layers.

> But if e.g you build for machine 'foo' and you have set
> COMPATIBLE_MACHINE_foo = "foo" in the .bbappend in your layer that
> does not mask the recipe for the 'bar' machine.

right (If I'm following what you are saying correctly), that's what I would
expect .. I don't want to mask it for machine 'bar'.

> (Think about including the full meta-intel layer and having a custom
> kernel for say cedartail: the other machines would have now multiple
> kernel providers)
> If you set instead COMPATIBLE_MACHINE = "foo" you are sure this recipe
> will be ignored by other machines.

Maybe I'm just thinking about the layout differently, I'm talking about a single
linux-yocto-custom, that all boards use .. so there wouldn't be
multiple providers,
if there were, they'd have different names and preferred version/provider would
clear up the ambiguity .. or maybe I'm just misunderstanding

>
>>
>> The goal is to set a base which is incompatible with all machines, and then
>> suggest that you must have a machine or other layer that adds your
>> explicit compatibility (I know I'm stating the obvious) .. and using a machine
>> specific override to do that is one good way to be clear and avoid overly long
>> and complex series of |'d (is that a word?) machines that can cause append
>> problems in their own right.
>>
>> So I'd think that an update to the comment that included COMPATIBLE_MACHINE
>> or COMPATIBLE_MACHINE_append would be a good addition, but I wouldn't
>> drop the existing text .. just augment it if we want.
>
> COMPATIBLE_MACHINE_append  is ok, I'm concerned by the _yourmachine scope

I still think both work, just different use cases and layouts.

>
>>
>> Good comment though.
>>
>> Cheers,
>>
>> Bruce
>
> BTW, cgit color-syntax dislikes the missing double-quotes in the
> coment at #39 :)

Patches accepted! I'm syntax highlight free when I view it, but I always
hate that myself when editing code!

Bruce

>
> Regards
>
> Andrea
>
>>
>>>
>>> My 2 cents
>>>
>>> Andrea
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



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