On Sun, Mar 29, 2009 at 05:52:43PM +0200, Manuel Lauss wrote: > From: Manuel Lauss <mano@xxxxxxxxxxxxxxxxxxxxxxx> > Date: Sun, 29 Mar 2009 17:52:43 +0200 > To: Kevin Hickey <khickey@xxxxxxxxxxx> > Cc: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx>, > Linux-MIPS <linux-mips@xxxxxxxxxxxxxx> > Subject: Re: [PATCH 0/3] Alchemy: platform updates > Content-Type: text/plain; charset=US-ASCII > > On Sun, 29 Mar 2009 10:27:46 -0500 > Kevin Hickey <khickey@xxxxxxxxxxx> wrote: > > > 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 :) > > You're right, from a single-cpu-board POV it doesn't make sense. > However if you have a few boards which mostly differ in the Alchemy > chip used (and not much else difference in board support code), I find > this to be highly beneficial. If I can have a single binary for the > folks testing these boards, all the better! > > Yes, increased binary size is to be expected, but I don't expect it to > be in the megabyte range. > > I'm primarily doing this for company-internal purposes; I just thought > I'd share the final result, maybe someone else might find it useful. In the past the Alchemy code has frequently suffered from small silly bugs that were affecting only a part of the Alchemy platforms. If code was more generic there would be the additional benefit of improved test coverage without more testing. I frequently see people still optimizing code as if the problem was still squeezing a program into a 2716 EPROM for an 8085. Trading a few bytes or microseconds of startup time for sanity is a really good thing! Ralf
