[linux-yocto] [PATCH 5/5] kconfig: make CONFIG_BLOCK=y part of base config

[Bruce Ashfield]

On 12-07-27 05:49 PM, Darren Hart wrote:
>
>
> On 07/27/2012 11:55 AM, Bruce Ashfield wrote:
>> On 12-07-27 12:25 PM, Paul Gortmaker wrote:
>>> This has largely no effect, since the default is y, and since
>>> it is as fundamental as CONFIG_NET, it should be in the base.
>>> Move it there and delete any other instances of it.  This will
>>> resolve any BSP configuration audit warnings on CONFIG_BLOCK
>>> caused by a BSP that includes scsi.
>>>
>>> Signed-off-by: Paul Gortmaker<paul.gortmaker at windriver.com>
>>> ---
>>>    meta/cfg/kernel-cache/cfg/efi-ext.cfg        | 1 -
>>>    meta/cfg/kernel-cache/features/scsi/scsi.cfg | 1 -
>>>    meta/cfg/kernel-cache/ktypes/base/base.cfg   | 1 +
>>>    3 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/meta/cfg/kernel-cache/cfg/efi-ext.cfg b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
>>> index 6371da2..b3bb91a 100644
>>> --- a/meta/cfg/kernel-cache/cfg/efi-ext.cfg
>>> +++ b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
>>> @@ -4,7 +4,6 @@
>>>    # efi.cfg
>>>    CONFIG_FB=y
>>>    CONFIG_VT=y
>>> -CONFIG_BLOCK=y
>>
>> Random question. If we leave this in place, it leaves efi-ext standalone
>> to be used on any baseline (I'm thinking poky-tiny here) if it has
>> its own copy of config_block.
>>
>> So my question is that we should definitely move this into base as far
>> as I'm concerned, but do we also want to leave it in efi-ext ? ..
>>
>> Any preference Darren ?
>
> Seems to me this should move into standard/base (is that what you meant?)

Yes, base is a good spot for this, so I did mean this part.

>
> As BLOCK is not the default of all baselines (ie tiny) it doesn't make
> sense to me to remove it from fragments that depend on it. I take the
> approach that my fragments should be complete as much as possible (even
> if because the scc file includes other scc files to fulfill that).

And this part as well.

There are two ways to manage .scc files, make them completely 
non-overlapping
and when they are included you get everything you need for the system.
This is good for consistency and maintenance of options (no dups, no
overrides, etc), but it takes a lot of control, since shuffling them
around has to happen periodically due to new uses and features.

Keeping each feature as specifying everything that it needs to be complete
is the other option, and the one that I generally prefer. It trades
a few gotchas with overrides and multiply provided values for features
that can be included from any other feature and "just work".

So I'm thinking I'd like to keep config_block in the EFI stub as well
as having it in base.

Cheers,

Bruce

>
> --
> Darren
>
> --
> Darren
>
>>
>> Bruce
>>
>>>    CONFIG_PARTITION_ADVANCED=y
>>>
>>>    # Add support for optional EFI features
>>> diff --git a/meta/cfg/kernel-cache/features/scsi/scsi.cfg b/meta/cfg/kernel-cache/features/scsi/scsi.cfg
>>> index 0965a80..2e9142f 100644
>>> --- a/meta/cfg/kernel-cache/features/scsi/scsi.cfg
>>> +++ b/meta/cfg/kernel-cache/features/scsi/scsi.cfg
>>> @@ -1,2 +1 @@
>>> -CONFIG_BLOCK=y
>>>    CONFIG_SCSI=y
>>> diff --git a/meta/cfg/kernel-cache/ktypes/base/base.cfg b/meta/cfg/kernel-cache/ktypes/base/base.cfg
>>> index 251011a..0c8b615 100644
>>> --- a/meta/cfg/kernel-cache/ktypes/base/base.cfg
>>> +++ b/meta/cfg/kernel-cache/ktypes/base/base.cfg
>>> @@ -49,6 +49,7 @@ CONFIG_EPOLL=y
>>>    CONFIG_MODULES=y
>>>    CONFIG_MODULE_UNLOAD=y
>>>    CONFIG_KMOD=y
>>> +CONFIG_BLOCK=y
>>>
>>>    #
>>>    # Beancounters
>>
>