* [PATCH] linux-yocto-custom: Clarify defconfig usage @ 2012-10-03 4:36 Darren Hart 2012-10-03 4:38 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Darren Hart @ 2012-10-03 4:36 UTC (permalink / raw) To: openembedded-core; +Cc: Darren Hart 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(-) 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 -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto-custom: Clarify defconfig usage 2012-10-03 4:36 [PATCH] linux-yocto-custom: Clarify defconfig usage Darren Hart @ 2012-10-03 4:38 ` Bruce Ashfield 2012-10-03 12:10 ` Andrea Adami 0 siblings, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2012-10-03 4:38 UTC (permalink / raw) To: Darren Hart; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto-custom: Clarify defconfig usage 2012-10-03 4:38 ` Bruce Ashfield @ 2012-10-03 12:10 ` Andrea Adami 2012-10-03 12:33 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Andrea Adami @ 2012-10-03 12:10 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto-custom: Clarify defconfig usage 2012-10-03 12:10 ` Andrea Adami @ 2012-10-03 12:33 ` Bruce Ashfield 2012-10-03 14:07 ` Andrea Adami 0 siblings, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2012-10-03 12:33 UTC (permalink / raw) To: Andrea Adami; +Cc: openembedded-core 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 -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto-custom: Clarify defconfig usage 2012-10-03 12:33 ` Bruce Ashfield @ 2012-10-03 14:07 ` Andrea Adami 2012-10-03 14:41 ` Bruce Ashfield 2012-10-03 14:43 ` Darren Hart 0 siblings, 2 replies; 7+ messages in thread From: Andrea Adami @ 2012-10-03 14:07 UTC (permalink / raw) To: openembedded-core 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" ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto-custom: Clarify defconfig usage 2012-10-03 14:07 ` Andrea Adami @ 2012-10-03 14:41 ` Bruce Ashfield 2012-10-03 14:43 ` Darren Hart 1 sibling, 0 replies; 7+ messages in thread From: Bruce Ashfield @ 2012-10-03 14:41 UTC (permalink / raw) To: Andrea Adami; +Cc: openembedded-core 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 -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto-custom: Clarify defconfig usage 2012-10-03 14:07 ` Andrea Adami 2012-10-03 14:41 ` Bruce Ashfield @ 2012-10-03 14:43 ` Darren Hart 1 sibling, 0 replies; 7+ messages in thread From: Darren Hart @ 2012-10-03 14:43 UTC (permalink / raw) To: Andrea Adami; +Cc: openembedded-core 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. -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-10-03 14:56 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-03 4:36 [PATCH] linux-yocto-custom: Clarify defconfig usage Darren Hart 2012-10-03 4:38 ` Bruce Ashfield 2012-10-03 12:10 ` Andrea Adami 2012-10-03 12:33 ` Bruce Ashfield 2012-10-03 14:07 ` Andrea Adami 2012-10-03 14:41 ` Bruce Ashfield 2012-10-03 14:43 ` Darren Hart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox