Prev: [RFC] Tight check of pfn_valid on sparsemem
Next: sparc: move is_root_node from private header to of.h
From: Uwe Kleine-König on 12 Jul 2010 12:00
Hi Linus,

On Wed, Jun 30, 2010 at 12:40:43PM +0200, Uwe Kleine-K�nig wrote:
> I think my mail hit your inbox during your vacation. As this is quite
> important for the ARM people and there isn't much time left, can you
> please comment?
As you havn't replied up to now I wonder if that just means that you
still plan to remove all defconfig files or if you are just busy doing
other things.

Thanks
Uwe

--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 12 Jul 2010 13:40
On Mon, Jul 12, 2010 at 09:51:47AM -0700, Linus Torvalds wrote:
> So if the ARM people decide that your script is a good way to clean up
> the mess, I might be happy with that. But that would require that they
> NEVER EVER try to push me a update that contains an un-cleaned-up
> defconfig file.

Does this mean that you aren't going to delete all the defconfigs
during the next merge window if we come up with an alternative
solution to yours?

When you brought up the problem you seemed absolutely convinced
that nothing except your solution was going to be acceptable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 12 Jul 2010 15:10
2010/7/12 Uwe Kleine-K�nig <u.kleine-koenig(a)pengutronix.de>:
>
> I'm willing to try my solution, some others on the linux-arm-kernel
> lists considered it worth trying, too. �Feel free to pull my tree[1].
> Russell refused to take defconfig changes for a while now, so I don't
> expect merge problems if you do.

Well, I can hardly refuse a pull that removes almost 200k lines. So
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.

- 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.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nicolas Pitre on 12 Jul 2010 15:20
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 12 Jul 2010 15:40
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico(a)fluxnic.net> wrote:
>>
>> � �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.

You aren't really answering the question. The thing is, the wholesale
removal wouldn't happen during the late -rc anyway, and it wouldn't
cause any merge issues (merge conflicts where the file is just to be
removed are trivial to take care of).

So I'm really asking about the issue of "how does this work during the
late -rc phase". Where the _timing_ is the important thing.

Because I could as easily pull after 2.6.35 is out. That has it's own
downsides (with all the merging going on), but at the same time, it's
clearly the right time for a large change.

So when I ask about timing and "how does this work in late -rc", it's
really about how safe it is to do now. Because if it isn't very
obviously safe, I can't pull it.

One part of the "obviously safe" thing is verification for each
defconfig file that the end result is identical with the reduced
version. Uwe implied that it was, and that was clearly the intention,
but was there some explicit verification that yes, the
before-and-after configurations are 100% the same?

Also, I assume that while it's _mostly_ a transparent change to users,
it does require that people do "make oldconfig" with the reduced
defconfig file first, in order to avoid having to answer with the
defaults. No? And the reduced defconfig files obviously do depend on
the default in the Kconfig files themselves, so it does have that kind
of fairly subtle semantic change that may not be entirely obvious or
easy to notice.

So from a timing standpoint, I just want to be convinced that "late
-rc" really is the right thing. I'm not entirely sure it is, even
though I do see advantages.

> 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.

Quite possible. But maintainers would need to be on the lookout of
people actually using the script, and refusing to apply patches that
re-introduce the whole big thing.

I also haven't actually seen the script - I don't think Uwe ever
posted it - so maybe it's some very fragile thing. Hard to judge on no
real information ;^p

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [RFC] Tight check of pfn_valid on sparsemem
Next: sparc: move is_root_node from private header to of.h