On 07/29/2011 07:40 AM, Nicolas Pitre wrote:
On Fri, 29 Jul 2011, Dave Martin wrote:
On Thu, Jul 28, 2011 at 02:44:17PM -0400, Nicolas Pitre wrote:
On Thu, 28 Jul 2011, Dave Martin wrote:
I have a slightly biased interest in this, since ARM seems to like funky memory maps for many of its newer boards, and it would be unfortunate for these to get left out of the whole single effort.
Of course we could include those platforms in non-sparsemem kernels, but since that will often mean sacrificing half the RAM, this is far from ideal.
Maybe that half could simply be pushed to home.
Eh?
Euh... I meant "himem". No idea how my fingers turned that into "home".
We could even embed the printch() function body into the DT if we wanted to make the kernel's job even simpler. Realistic implementations of this function are tiny, so this shouldn't be too cumbersome. That really seems an abuse of the DT though, since this goes beyond just describing the hardware.
Well... I'm not entirely against the idea. This could be seen as the most efficient way to describe how to output a character over some serial device for the given hardware. The danger is that some vendors might be tempted to abuse that idea by stuffing BIOS-like services in there that the kernel would have to cope with.
See my reply to Arnd...
What might be done is to describe the data FIFO register location, and the FIFO full bit mask, and the FIFO empty bit mask. That's all we need really.
Except for RPC which outputs to video memory. We don't care about that one for single kernel, but that may limit a new common solution.
BTW, I did implement a conversion to use debug macro code for uncompress, but it doesn't work for RPC, OMAP and Davinci. So while it shrinks the the code by over 2K lines, we probably need a new approach like you suggest. The patches are here if you want to take a look:
git://git.jdl.com/software/linux-3.0.git http://git.jdl.com/gitweb/?p=linux-3.0.git%3Ba=shortlog%3Bh=refs/heads/uncom...
Rob