[Buildroot] Linux arch default cfgs and fragments

[Buildroot] Linux arch default cfgs and fragments

[Matthew Weber]

Wanted to open the debate on the topic of using arch defconfigs and
the negatives of where fragments may over time or between target
kernel minor revisions have different end results because of the arch
defconfig default state.

I'm wondering if when a arch defconfig is used the fragments against
it should be validated as actually being in the final expanded
config....  I see the merge config script has support to validate this
but by default it isn't part of the process.

Thoughts?

-- 
Matthew Weber | Pr. Software Engineer | Commercial Avionics
COLLINS AEROSPACE
400 Collins Road NE, Cedar Rapids, Iowa 52498, USA
Tel: +1 319 295 7349 | FAX: +1 319 263 6099
matthew.weber at collins.com | collinsaerospace.com

[Buildroot] Linux arch default cfgs and fragments

[Arnout Vandecappelle]

On 24/04/2019 19:38, Matthew Weber wrote:
> Wanted to open the debate on the topic of using arch defconfigs and
> the negatives of where fragments may over time or between target
> kernel minor revisions have different end results because of the arch
> defconfig default state.
> 
> I'm wondering if when a arch defconfig is used the fragments against
> it should be validated as actually being in the final expanded
> config....  I see the merge config script has support to validate this
> but by default it isn't part of the process.

 I'm not sure in which context you're talking here. Is it for the in-tree
defconfigs? For those, it's fine for me if the exact configuration changes when
the kernel gets bumped, and it's up to the person doing the bump to make sure
that it stays reasonable/usable.

 Or is your suggestion that for our defconfigs, we should switch to the arch
defconfig + fragments as the general rule? I don't really agree with that. I'm
under the impression that the arch defconfigs are not very usable. They tend to
enable almost everything, seemingly randomly sometimes as module and sometimes
linked in. For example, the ARM defconfig has roughly 900 drivers...

 If it is for how users are maintaining their kernel configs, I don't think
there's anything we should prescribe.

 Regards,
 Arnout

[Buildroot] Linux arch default cfgs and fragments

[Matthew Weber]

Arnout,

On Sat, Apr 27, 2019 at 4:58 PM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 24/04/2019 19:38, Matthew Weber wrote:
> > Wanted to open the debate on the topic of using arch defconfigs and
> > the negatives of where fragments may over time or between target
> > kernel minor revisions have different end results because of the arch
> > defconfig default state.
> >
> > I'm wondering if when a arch defconfig is used the fragments against
> > it should be validated as actually being in the final expanded
> > config....  I see the merge config script has support to validate this
> > but by default it isn't part of the process.
>
>  I'm not sure in which context you're talking here. Is it for the in-tree
> defconfigs? For those, it's fine for me if the exact configuration changes when
> the kernel gets bumped, and it's up to the person doing the bump to make sure
> that it stays reasonable/usable.
>

Yes for the in-tree arch default configs.  I think we should be
running a configuration check on those when used with fragments to
help the developer know that the fragments are working.

>  Or is your suggestion that for our defconfigs, we should switch to the arch
> defconfig + fragments as the general rule? I don't really agree with that.

Nope not suggesting that.

>  If it is for how users are maintaining their kernel configs, I don't think
> there's anything we should prescribe.

I was just curious if we can make the use of fragments a bit more
foolproof as options get dropped and you have to watch the warnings to
catch when they do.  (Hopefully my response above was clear.  Just
this arch default case or even when initially setting up fragments, it
would be nice to validate they are doing what's intended to the
config)

Matt

[Buildroot] Linux arch default cfgs and fragments

[Arnout Vandecappelle]

On 29/04/2019 16:39, Matthew Weber wrote:
[snip]
> I was just curious if we can make the use of fragments a bit more
> foolproof as options get dropped and you have to watch the warnings to
> catch when they do.

 OK, so your suggestion is to add a check that after fragments have been
applied, the resulting .config indeed contains the contents of the fragments.
Similar to the check we have in e.g. test-pkg for SKIPPED.

 The question is: do you want to make this an error or a warning? I think we
can't make it an error, because there are use cases where you expect the
fragment not to apply. I don't have a concrete example for the kernel config,
but for Buildroot configs I have some fragments that I sometimes use that set
defaults for some string options (e.g. for kernel defconfig to use), and that
only really apply to the defconfig in which the kernel is built, but that gets
applied everywhere (i.e. for all defconfigs for that particular board). So I'd
have four defconfigs for four different configurations which are independent of
the board, and then four config fragments for four different board types, with a
total of sixteen different .config files, but only four of those actually have a
kernel.

 Anyway, my point is: we can't really predict what the use case for config
fragments is, so we can't make it an error.

 And I do think it's already a warning. But of course, that warning gets
completely lost in the build log.

 In general, I think managing config fragments is far out of scope for
Buildroot. We might add some tools to make managing them easier (without
enforcing a particular workflow) but even that is a bit out of scope IMO. The
<pkg>-diff-config target from almost a year ago that is still floating around on
patchwork is already borderline IMO.

 Regards,
 Arnout

[Buildroot] [External] Re: Linux arch default cfgs and fragments

[Matthew Weber]

On Mon, Apr 29, 2019 at 9:51 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 29/04/2019 16:39, Matthew Weber wrote:
> [snip]
> > I was just curious if we can make the use of fragments a bit more
> > foolproof as options get dropped and you have to watch the warnings to
> > catch when they do.
>
>  OK, so your suggestion is to add a check that after fragments have been
> applied, the resulting .config indeed contains the contents of the fragments.
> Similar to the check we have in e.g. test-pkg for SKIPPED.
>
>  The question is: do you want to make this an error or a warning? I think we
> can't make it an error, because there are use cases where you expect the
> fragment not to apply. I don't have a concrete example for the kernel config,
> but for Buildroot configs I have some fragments that I sometimes use that set
> defaults for some string options (e.g. for kernel defconfig to use), and that
> only really apply to the defconfig in which the kernel is built, but that gets
> applied everywhere (i.e. for all defconfigs for that particular board). So I'd
> have four defconfigs for four different configurations which are independent of
> the board, and then four config fragments for four different board types, with a
> total of sixteen different .config files, but only four of those actually have a
> kernel.

Agree, the script already makes the check optional through how you
provide arguments.  I think it would just be modifying how the kconfig
infra uses the script to merge.

>
>  Anyway, my point is: we can't really predict what the use case for config
> fragments is, so we can't make it an error.
>
>  And I do think it's already a warning. But of course, that warning gets
> completely lost in the build log.

Yep.....

>
>  In general, I think managing config fragments is far out of scope for
> Buildroot. We might add some tools to make managing them easier (without
> enforcing a particular workflow) but even that is a bit out of scope IMO. The
> <pkg>-diff-config target from almost a year ago that is still floating around on
> patchwork is already borderline IMO.
>

Agree.  Was just hoping to cleanup how we do merges as there are
errors introduced occasionally that aren't noticed until you have a
build in the lab.  If I can prevent that from occurring, I'll try :-)

Matt