[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48061B36.20800@seznam.cz>
Date: Wed, 16 Apr 2008 17:28:54 +0200
From: Michal Simek <monstr@...nam.cz>
To: Arnd Bergmann <arnd@...db.de>
CC: Paul Mackerras <paulus@...ba.org>, benh@...nel.crashing.org,
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
Subject: Re: Microblaze Linux release
>>> 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 have a commit queued up that moves lmb.c into the top-level lib
>> directory so other architectures can use it easily. Dave Miller
>> wanted this so he could use it for sparc64. That will go into Linus'
>> tree when the merge window opens and will be in 2.6.26. So I don't
>> see any reason why microblaze couldn't use the LMB stuff.
>>
>
> Right, fair enough. I was mostly objecting to the idea of creating another
> copy of the lmb code when bootmem should be sufficient for what microblaze
> needs. Using the code from lib/lmb.c sounds fair enough when it's already
> there.
>
> One more reason for the microblaze kernel to base on top of linux-next
> instead of mainline.
For me is not difficult to use lmb from microblaze/mm or from lib if the files
are the same.
Michal Simek
--
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