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]

Message-ID: <1275584003.23384.2.camel@c-dwalke-linux.qualcomm.com>
Date:	Thu, 03 Jun 2010 09:53:23 -0700
From:	Daniel Walker <dwalker@...eaurora.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Russell King <rmk@....linux.org.uk>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org,
	Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: ARM defconfig files

On Thu, 2010-06-03 at 07:48 -0700, Linus Torvalds wrote:
> [ Continuation on the "ARM MSM updates" thread ]
> 
> On Thu, 3 Jun 2010, Russell King wrote:
> >
> > It'd be nice if you'd copy me...
> 
> Yeah, the thread started out as a "I got really bored with lots of msm 
> patches", and then just expanded into what I think is wrong with the 
> sub-architectures. 
> 
> > On the defconfig files, you may not like them - I don't like the
> > proliferation of them either.  What I've always wanted to see is
> > one defconfig per class of machines - in other words, one mach-XXX.
> 
> I can understand that, but at the same time, I do think that the 
> "defconfig" file concept as it is now is just broken. To the point of 
> being unfixable. It's obviously just a copy of the final .config, and it's 
> fundamentally not really readable (and especially not writable) by humans.
> 
> And that all actually made some sense way-back-when, back when it was 
> originally done - back when our config files were tiny (compared to what 
> they are now), and when it ended up being the default input for the 
> config. It just doesn't make much sense any more. The Kconfig files 
> themselves end up having defaults for the core things, and the non-core 
> things are too many to list/edit sanely in that format.
> 
> So the original reason I want to remove them is that they are very 
> annoying, but the reasoning that then takes that annoyance and makes me 
> think seriously about removing them despite the inevitable pain factor is 
> that I really don't think we can even use the concept for any better 
> model.
> 
> Anything better would _have_ to be totally different. And no, I don't 
> think your "diffs against a base" model work either, because while it 
> would make them smaller, it would still make them basically unreadable and 
> uneditable by any human, which means that it's not something we should 
> check in - it's a generated file!

Have you noticed this ..

http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130

I'm not sure of the goals, but it sounds like it might be relevant.

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/