ARM defconfig files

[Nicolas Pitre]

On Mon, 12 Jul 2010, Linus Torvalds wrote:

> I'd happily pull it. Just this single line in your email is a very
> very powerful thing:
> 
> >  177 files changed, 652 insertions(+), 194157 deletions(-)
> 
> However, before I would pull, I'd definitely like to make sure we at
> least have some way forward too, and clarify some issues. So I have a
> couple of questions:
> 
>  - is this guaranteed to be a no-op as things stand now, and what are
> the secondary effects of it?
> 
>    Put another way: I realize that fairly late in the -rc series is
> actually a really good time to do this, rather than during the merge
> window itself when things are in flux. However, while it would be a
> good time to pull this for that reason, it's also a _horrible_ time to
> pull if it then regresses the defconfig uses, or if it causes horrible
> problems for linux-next merging etc.

This cannot be any worse than wholesale removal of those files as you 
were contemplating at some point.  Furthermore, on ARM we have someone 
providing automatic rebuild of all defconfigs already, so any serious 
issue should be noticed right away.

>  - what happens when somebody wants to update the defconfig files?
> 
>    This is a question that involves a number of people, because over
> the last half year, we've had lots of people changing them. "git
> shortlog -ns" on that ARM config directory gives 39 people in the last
> half year, with the top looking roughly like
> 
>     26  Ben Dooks
>     10  Tony Lindgren
>      4  Haojian Zhuang
>      4  Kukjin Kim
>      3  Santosh Shilimkar
>      3  Sriram
>      2  Janusz Krzysztofik
>     ....
> 
> and how are these people going to do their updates going forward
> without re-introducing the noise?
> 
> IOW, I'd _love_ to get rid of almost 200k lines of noise and your
> approach would seem to have the advantage that it's "invisible" to
> users. But I would want to get some kind of assurance that it's
> practical to do so.

I think Uwe could provide his script and add it to the kernel tree.  
Then all architectures could benefit from it.  Having the defconfig 
files contain only those options which are different from the defaults 
is certainly more readable, even on x86.


Nicolas