linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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()

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