Patchwork linux-yocto-custom: Clarify defconfig usage

login
register
mail settings
Submitter Darren Hart
Date Oct. 3, 2012, 4:36 a.m.
Message ID <52507f028d9ec0e88078673e15e238d010cfaead.1349239001.git.dvhart@linux.intel.com>
Download mbox | patch
Permalink /patch/37649/
State Accepted
Commit 6d1aa1dc3131237a481fcada3bbe13c182136169
Headers show

Comments

Darren Hart - Oct. 3, 2012, 4:36 a.m.
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).

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Bruce Ashfield - Oct. 3, 2012, 4:38 a.m.
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@windriver.com>

>
> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
> CC: Bruce Ashfield<bruce.ashfield@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
Andrea Adami - Oct. 3, 2012, 12:10 p.m.
On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield
<bruce.ashfield@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@windriver.com>
>
>
>>
>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
>> CC: Bruce Ashfield<bruce.ashfield@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@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.

My 2 cents

Andrea
Bruce Ashfield - Oct. 3, 2012, 12:33 p.m.
On Wed, Oct 3, 2012 at 8:10 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield
> <bruce.ashfield@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@windriver.com>
>>
>>
>>>
>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
>>> CC: Bruce Ashfield<bruce.ashfield@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@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.

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.

Good comment though.

Cheers,

Bruce

>
> My 2 cents
>
> Andrea
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Andrea Adami - Oct. 3, 2012, 2:07 p.m.
On Wed, Oct 3, 2012 at 2:33 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> On Wed, Oct 3, 2012 at 8:10 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
>> On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield
>> <bruce.ashfield@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@windriver.com>
>>>
>>>
>>>>
>>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
>>>> CC: Bruce Ashfield<bruce.ashfield@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@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.
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.
(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.

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

>
> Good comment though.
>
> Cheers,
>
> Bruce

BTW, cgit color-syntax dislikes the missing double-quotes in the
coment at #39 :)

Regards

Andrea

>
>>
>> My 2 cents
>>
>> Andrea
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@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"
Bruce Ashfield - Oct. 3, 2012, 2:41 p.m.
On Wed, Oct 3, 2012 at 10:07 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> On Wed, Oct 3, 2012 at 2:33 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> On Wed, Oct 3, 2012 at 8:10 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
>>> On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield
>>> <bruce.ashfield@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@windriver.com>
>>>>
>>>>
>>>>>
>>>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
>>>>> CC: Bruce Ashfield<bruce.ashfield@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@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@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Darren Hart - Oct. 3, 2012, 2:43 p.m.
On 10/03/2012 07:07 AM, Andrea Adami wrote:
> On Wed, Oct 3, 2012 at 2:33 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> On Wed, Oct 3, 2012 at 8:10 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
>>> On Wed, Oct 3, 2012 at 6:38 AM, Bruce Ashfield
>>> <bruce.ashfield@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@windriver.com>
>>>>
>>>>
>>>>>
>>>>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
>>>>> CC: Bruce Ashfield<bruce.ashfield@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@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.
> 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.
> (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.

Are you saying that if users replace:

COMPATIBLE_MACHINE = "(^$)"

with

COMPATIBLE_MACHINE_foo = "foo"

That COMPATIBLE_MACHINE will default to "" for all the other machines
and be implicitly marked as compatible?

If so... I believe you are correct and that is not the desired behavior.
the _machine is appropriate for bbappend files, but for custom bb files
as this is meant to be used, a proper regex should be used.

Care to submit a documentation patch for this?

Thanks for the comments.

Patch

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