[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48059B92.7080601@seznam.cz>
Date: Wed, 16 Apr 2008 08:24:18 +0200
From: Michal Simek <monstr@...nam.cz>
To: benh@...nel.crashing.org
Cc: Arnd Bergmann <arnd@...db.de>,
Stephen Neuendorffer <stephen.neuendorffer@...inx.com>,
John Williams <john.williams@...alogix.com>,
jwboyer@...ux.vnet.ibm.com, John Linn <John.Linn@...inx.com>,
git-dev@...inx.com, Grant Likely <grant.likely@...retlab.ca>,
git@...inx.com, microblaze-uclinux@...e.uq.edu.au,
linux-kernel@...r.kernel.org, paulus@...ba.org
Subject: Re: Microblaze Linux release
Hi Ben,
>> I'd recommend splitting prom.c into code that can be shared between powerpc
>> and microblaze and architecture specific code. Anything that deals with
>> LMB should go into powerpc, and you can simply use the alloc_bootmem
>> mechanism for your architecture.
>
> That is non trivial... the unflatten DT code among others relies heavily
> on the LMB's to allocate the objects.
I think so. Sharing code among archs looks nice and this way is definitely
right. But starting with communication with PowerPC guys that this code I want
to use in case that this code is not in vanilla. This is not good start for
doing this.
I think if Microblaze will be in vanilla we can talked about separation MB and
PPC part to kernel folder and shared code move to shared folder.
> We could split the early accessors, unflatten code, and kernel-side
> accessors at one point, though we already did most of it no ?
Yes
Michal Simek
www.monstr.eu
--
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