From: Paul M. <pau...@re...> - 2007-08-03 04:43:07
|
On Fri, Aug 03, 2007 at 12:33:06AM -0400, Mike Frysinger wrote: > On Friday 03 August 2007, Paul Mundt wrote: > > In any event, supporting multiple boards is fairly trivial, but you give > > up link-time size savings and push most of that down to freeing of init > > memory. It works out the same in the end, the main factor is how > > constrained you are in kernel size. Some platforms (ie, hppa) also make > > function pointers quite expensive, so there are also performance > > reasons why you may wish to avoid the extra layer of indirection. > > thanks, i'll keep these things in mind ... the reason we dont have multiple > board support is lack of customer demand -- we have yet to find one who said > they wanted/needed this. as soon as one does though, we'll most likely go > down that route (and steal ideas from people like sh who've already done it). I generally use it more for new CPU/board support, it's fairly convenient to be able to switch between board-specific I/O ops and the generic ones. This can save quite a bit of time if you have both PIO and MMIO to contend with, particularly on brain-dead SuperIOs interfaced with a disagreeable-but-fixed buswidth. Though when faced with these things, you would be much better off simply prying the entire SuperIO package off of your board and running far away, or barring that, throwing the board away. |