[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071024121218.GA23548@elte.hu>
Date: Wed, 24 Oct 2007 14:12:18 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Sam Ravnborg <sam@...nborg.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Linux v2.6.24-rc1
* Sam Ravnborg <sam@...nborg.org> wrote:
> On Wed, Oct 24, 2007 at 09:04:51AM +0100, Christoph Hellwig wrote:
> > On Tue, Oct 23, 2007 at 09:19:16PM -0700, Linus Torvalds wrote:
> > > In short, we just had an unusually large amount of not just x86 merges,
> >
> > Btw, can we please finis up this merge a little more before we freeze
> > 2.6.24? The way we currently have leftovers of arch/i386/ and arch/x86_64/
> > is quite a nightmare and not how the other architectures were merged.
>
> If these 10 files gives you nightmares then poor soul ;-)
>
> Anyway - the primary issue is the two defconfig files and the Kconfig stuff.
> For defconfig we can inheritate the solution from powerpc where
> the defconfig file is selected based on architecture.
> Something like a
> DEFCONFIG := defconfig_$(ARCH)
>
> and then stuff them in configs/ directory.
>
> The Kconfig stuff could be handled by special casing in scripts/kconfig.
> We cannot just do the more obvious which is source the files since
> they have conflicting choice symbols.
> That could be fixed but requires a bit more work to do so - since we need
> to track all relevant usages of the choice symbols and rename these.
> We could also teach kconfig to allow duplicate symbols names in two choices
> but Roman Zippel has not done that yet.
>
> The Makefile stuff is trivial to merge.
yes. But even Makefile merging can be surprisingly nontrivial at times:
we had bugs in earlier versions of the unification due to link ordering
and silent init section dependencies in the code. When we unified the
makefiles certain init code broke because the initcall ordering changed.
That's why we went for the "stupid, mechanic unification" approach first
- to always have a 100% correct fallback position that people can bisect
to.
Ingo
-
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/
Powered by blists - more mailing lists