linux-kernel - Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

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:	Fri, 04 Jun 2010 13:34:32 +0800
From:	Eric Miao <eric.y.miao@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Michael Ellerman <michael@...erman.id.au>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Daniel Walker <dwalker@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1

On 06/03/2010 12:26 PM, Linus Torvalds wrote:
> 
> 
> On Thu, 3 Jun 2010, Michael Ellerman wrote:
>>
>> You can sort of do that today, by just storing a delta, but oldconfig
>> will silently turn off things you have enabled if prereqs change, so
>> that doesn't really work I think.
> 
> I think you can do it today with various hacks. Up to and including 
> basically doing something that just selects the options you want.
> 
> IOW, you could likely have a human-written Kconfig.<platform> file that 
> just does 
> 
> 	define_bool MYPLATFORM y
> 		select .. everything I need ..
> 
> 	include Kconfig.main
> 
> or a number of other tricks.
> 
> Ingo and the x86 folks (who I really think have done a very good job, and 
> there really aren't any crazy defconfig files there) have this "make 
> randconfig" together with scripted requirements so that you can actually 
> _boot_ the random config, just because the requirements make sure that the 
> things needed for booting on the test setup are selected.
> 
> I forget exactly what the build setup there is (Ingo described it to me 
> long time ago, but since I don't even want to have a build farm in my 
> home, I didn't care much).
> 
> But we certainly _can_ do a better job than the 'defconfig' thing that was 
> really never meant for the kind of use it sees in ARM/POWERPC/SH/MIPS, and 
> that really isn't appropriate for any manual editing (so people just run 
> "make oldconfig" with tweaking or something, and then use the newly 
> generated file).
> 

It certainly looks a better way to handle this. However, considering the
facts that there are so many platforms out there, and doing a transition
without breaking any of them is a lot work, it's actually easier to just
reduce the number of defconfig at this moment, provided that most ARM
platforms with the same SoC are able to be built into a single kernel.
There are some exceptions though, I'd suggest not to introduce any other
defconfig for these platforms until their problem is solved.

Russell has setup a thread for this issue in linux-arm-kernel ML, so
hopefully there will be a lot patches around to address it.

There are some specific problems with ARM, e.g. some platforms are really
not maintained for a long time, and even no way to find someone or some
machine to test. And even with one defconfig per SoC, there could still
be about > 60 defconfigs there (compared with 178 at this moment).

> And I suspect that it really is best to just remove the existing defconfig 
> files. People can see them in the history to pick up what the heck they 
> did, but no way will any sane model ever look even _remotely_ like them, 
> so they really aren't a useful basis for going forward.
> 
> But don't worry. It didn't happen this merge window, obviously.
> 
> 		Linus

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