From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM defconfig files
Date: Mon, 12 Jul 2010 21:59:56 +0200 [thread overview]
Message-ID: <20100712195956.GC14425@pengutronix.de> (raw)
In-Reply-To: <AANLkTim-O00n9YPv7w4VCKjN-ETLijyTHomWUn4mZtTV@mail.gmail.com>
Hi Linus,
On Mon, Jul 12, 2010 at 12:34:59PM -0700, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@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.
I hoped you to pull this in during the merge window, but doing it now is
OK for me, too.
> 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?
I'm pretty sure it's 100% save as I only kick a line in the defconfig if
the result doesn't change. Well, modulo bugs in my script. But now
that it's public you can convince yourself it's (hopefully) correct.
> 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?
No, $(make ..._defconfig) is enough to get the full .config.
> 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.
Right.
> 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
See attachment. It's just:
for each line:
kick $line if $(make ..._defconfig) results in the same config without $line
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
#! /usr/bin/env python
# vim: set fileencoding=utf-8 :
# Copyright (C) 2010 by Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
import re
import subprocess
import os
import sys
# This prevents including a timestamp in the .config which makes comparing a
# bit easier.
os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please'
# XXX: get these using getopt
kernel_tree = '' # os.path.join(os.environ['HOME'], 'gsrc', 'linux-2.6')
arch = 'arm'
target = sys.argv[1]
defconfig_src = os.path.join(kernel_tree, 'arch/%s/configs/%s' % (arch, target))
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
origconfig = list(open('.config'))
config = list(origconfig)
config_size = os.stat('.config').st_size
i = 0
while i < len(config):
print 'test for %r' % config[i]
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + 1:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
del config[i]
else:
i += 1
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config)
defconfig.close()
next prev parent reply other threads:[~2010-07-12 19:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100603074548.GA12104@flint.arm.linux.org.uk>
[not found] ` <alpine.LFD.2.00.1006030725420.8175@i5.linux-foundation.org>
[not found] ` <20100603181010.GA25779@flint.arm.linux.org.uk>
[not found] ` <1275589230.23384.19.camel@c-dwalke-linux.qualcomm.com>
[not found] ` <alpine.LFD.2.00.1006031119440.8175@i5.linux-foundation.org>
2010-06-14 8:32 ` ARM defconfig files Uwe Kleine-König
2010-06-30 10:40 ` Uwe Kleine-König
2010-07-12 15:55 ` Uwe Kleine-König
2010-07-12 16:51 ` Linus Torvalds
2010-07-12 17:32 ` Russell King - ARM Linux
2010-07-12 17:40 ` Linus Torvalds
2010-07-12 18:50 ` Uwe Kleine-König
2010-07-12 19:04 ` Linus Torvalds
2010-07-12 19:17 ` Nicolas Pitre
2010-07-12 19:34 ` Linus Torvalds
2010-07-12 19:50 ` Grant Likely
2010-07-13 7:07 ` Uwe Kleine-König
2010-07-13 8:07 ` optimized script [Was: ARM defconfig files] Uwe Kleine-König
2010-07-13 18:04 ` Olof Johansson
2010-07-13 23:39 ` Nicolas Pitre
2010-07-13 18:32 ` ARM defconfig files Grant Likely
2010-07-12 19:59 ` Uwe Kleine-König [this message]
2010-07-12 20:14 ` Nicolas Pitre
2010-07-12 19:09 ` Nicolas Pitre
2010-07-12 20:31 ` Arnd Bergmann
2010-07-12 20:50 ` Nicolas Pitre
2010-07-12 23:05 ` David Brown
2010-07-12 23:18 ` Linus Torvalds
2010-07-12 23:34 ` David Brown
2010-07-13 0:55 ` Nicolas Pitre
2010-07-14 9:13 ` Felipe Contreras
2010-07-14 13:20 ` Uwe Kleine-König
2010-07-14 17:37 ` Tony Luck
2010-07-13 18:32 ` Rob Landley
2010-07-12 20:06 ` Russell King - ARM Linux
2010-07-12 20:29 ` Nicolas Pitre
2010-07-12 21:54 ` Linus Torvalds
2010-07-14 9:21 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100712195956.GC14425@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).