Toru Nishimura wrote:

> > "There should be a architecture-level function for the purpose, and
> > indeed there is, but it's a bit annoying.  So we're going to use local
> > code instead, and put less-annoying but very similar hunks of code in
> > N places." ?!?!?!?
> >
> > Lose.
> 
> Ah, I place oppose here.  To choose a simple definite written
> alternative is worhtwhile of considering seriously.  I think it's
> sorta holly war which some NetBSD developers would love to argue.

I don't think that this is holy war territory.  In a nutshell, we don't
want code duplication - that leads to maintenance problems.  If (in as
others suggested the unlikely case) there really is going to be that
much dead wood that affects some ports by having a complete CPU list in
the identify code we can start to think about #ifdef'ing some sections
out based on config file options.

We should be making it easier for ports to support random CPUs - this
change only makes that more difficult.  Now we're in the situation where
to add support for a new CPU to a port we'll just copy the code from
another port.  If we decide to change the identification output for CPUs
(and this _has_ happened in the past), we'd now need to change it in N
places instead of one place.  These are just some of the maintenance
issues we'll hit...

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD CDs, Support and Service:    http://www.wasabisystems.com/