Re: Configuring a layer to support multiple targets

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 11-08-17 03:07 PM, Chris Tapp wrote:
> On 17 Aug 2011, at 16:18, Bruce Ashfield wrote:
>
>> In this sense, the defconfig is simply a name to trigger
>> specific processing. Just capture and call your .config
>> 'defconfig' and you'll get a translation of those settings
>> into the build.
>
>
> That's what I've done. I used 'make xconfig' to modify the .config file
> (resulting from bitbake -c compile virtual/kernel). However, turning off
> CONFIG_USB_SERIAL and saving the result as a defconfig isn't quite
> what's needed.
>
> Consider the .config fragment:
>
> CONFIG_USB_SERIAL=y
> CONFIG_USB_SERIAL_FTDI_SIO=y
>
> The corresponding defconfig fragment produced when usb serial is
> disabled in xconfig results is simply:
>
> # CONFIG_USB_SERIAL is not set
>
> When the defconfig is merged with the .config I get:
>
> # CONFIG_USB_SERIAL is not set
> CONFIG_USB_SERIAL_FTDI_SIO=y
>
> This means the FTDI module is still present in the kernel.
>
> I can get rid of these by manually adding 'not set' entries in the
> defconfig, but it would be easier if I could replace the .config rather
> than patch it.

The model is that you must explicitly chose values to modify
them, otherwise, they flow through. Last through the gate wins.
If you don't speak, others parts speak for the configuration.

In this case, you must be inheriting the common-pc kernel
configuration.

It's something to configure for the future, but that is working
as designed at the moment. The point is to be able to set a policy
for options that inheriting BSPs must explicitly disable.

The solutions two this are:

   - inherit from a base branch vs common-pc (assuming that
     I guessed right)
   - do the explicit disabling of already set options
   - convince us that the common-pc shouldn't be turning this
     on and trickle this option out to the leaf BSPs.

Cheers,

Bruce


>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto