linux-mips
[Top] [All Lists]

Re: [PATCH 0/3] Alchemy: platform updates

To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Subject: Re: [PATCH 0/3] Alchemy: platform updates
From: Kevin Hickey <khickey@rmicorp.com>
Date: Sun, 29 Mar 2009 10:27:46 -0500
Cc: Manuel Lauss <mano@roarinelk.homelinux.net>, Linux-MIPS <linux-mips@linux-mips.org>
In-reply-to: <49CF71BE.2070109@ru.mvista.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1238318822-4772-1-git-send-email-mano@roarinelk.homelinux.net> <49CF5CE6.1070003@ru.mvista.com> <20090329143802.0a09baca@scarran.roarinelk.net> <49CF71BE.2070109@ru.mvista.com>
Sender: linux-mips-bounce@linux-mips.org
On Sun, 2009-03-29 at 17:03 +0400, Sergei Shtylyov wrote:
>   Single kernel binary? If it's at all possible, I am all for it.

On some level, I agree but not at the expense of a larger kernel or
longer boot times.  Maybe I'm just not following how your implementation
works but it seems to me that runtime checks will add to boot time.
More importantly it adds to the kernel memory footprint as the tables of
constants for multiple CPUs will have to be compiled in.  If I'm
designing a board with an Au1250 in it, I don't care about the interrupt
numbers for Au1100 or Au1500.  This problem compounds when we introduce
Au1300 - several of its subsystems (like the interrupt controller) are
new requiring not only a new table of constants but a new object as
well.  In the desktop space I can understand this approach, but in the
embedded space it seems like an unnecessary resource burden.  

Please enlighten me :)

=Kevin
-- 
Kevin Hickey
Alchemy Solutions
RMI Corporation
khickey@rmicorp.com
P:  512.691.8044


<Prev in Thread] Current Thread [Next in Thread>