From: Linus Torvalds <torvalds@linux-foundation.org>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Kevin Hilman <khilman@deeprootsystems.com>,
Daniel Walker <dwalker@codeaurora.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1
Date: Wed, 2 Jun 2010 21:26:29 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1006022112320.8175@i5.linux-foundation.org> (raw)
In-Reply-To: <1275536698.22020.81.camel@concordia>
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).
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
next prev parent reply other threads:[~2010-06-03 4:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 21:52 Daniel Walker
2010-06-02 20:50 ` Daniel Walker
2010-06-02 21:27 ` Linus Torvalds
2010-06-02 21:39 ` Linus Torvalds
2010-06-02 21:56 ` Daniel Walker
2010-06-02 22:30 ` Daniel Walker
2010-06-02 23:27 ` Kevin Hilman
2010-06-03 1:20 ` Linus Torvalds
2010-06-03 3:44 ` Michael Ellerman
2010-06-03 4:26 ` Linus Torvalds [this message]
2010-06-03 16:11 ` Tony Lindgren
2010-06-04 5:34 ` Eric Miao
2010-06-03 4:45 ` Ben Dooks
2010-06-03 5:36 ` Ben Dooks
2010-06-04 8:27 ` Vincent Sanders
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=alpine.LFD.2.00.1006022112320.8175@i5.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=dwalker@codeaurora.org \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@ellerman.id.au \
/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
Powered by JetHome