[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0906161505080.16802@localhost.localdomain>
Date: Tue, 16 Jun 2009 15:06:23 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc: Christoph Lameter <cl@...ux-foundation.org>,
Nick Piggin <npiggin@...e.de>,
Pekka Enberg <penberg@...helsinki.fi>,
Heiko Carstens <heiko.carstens@...ibm.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
kamezawa.hiroyu@...fujitsu.com, lizf@...fujitsu.com, mingo@...e.hu,
yinghai@...nel.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31
On Wed, 17 Jun 2009, Benjamin Herrenschmidt wrote:
>
> I would normally agree ... but we still have some stuff in setup_arch()
> that will need that :-( IE, we need to allow ioremap very early on
> powerpc (and possibly various other archs that don't have magic PIO to
> whack their chipset without the need for a mapping), so we have tricks
> to allocate page tables using LMB, bootmem or slab depending on what's
> available that still rely on slab_is_available().
>
> Same goes with some PCI PHB related data structures that we are
> allocating in setup_arch() as well, though that's something I do intend
> to move to normal initcalls asap (there's a few skeletons hiding in some
> corners there so it's not totally trivial).
Both of these sound like they should be moved. Perhaps not to "normal
initcalls" (those do happen very late), but maybe to some slightly later
phase in init/main.c.
Why do you need ioremap so early that it has to happen before even the
basic MM data is up? That sounds bogus, and like just a random
implementation issue for historical reasons.
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/
Powered by blists - more mailing lists