linux-kernel - Re: ARM defconfig files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Jul 2010 21:59:56 +0200
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Nicolas Pitre <nico@...xnic.net>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Daniel Walker <dwalker@...eaurora.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Eric Miao <eric.miao@...onical.com>, linux-omap@...r.kernel.org
Subject: Re: ARM defconfig files

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@...xnic.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/  |

View attachment "reduce_defconfig" of type "text/plain" (1207 bytes)