The following reply was made to PR port-evbmips/31992; it has been noted by GNATS.

From: Simon Burge <simonb@wasabisystems.com>
To: garrett_damore@tadpole.com
Cc: gnats-bugs@netbsd.org, port-evbmips-maintainer@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-evbmips/31992: alchemy ICU is too Au1000 specific 
Date: Thu, 10 Nov 2005 14:02:05 +1100

 garrett_damore@tadpole.com wrote:
 
 > >Number:         31992
 > >Category:       port-evbmips
 > >Synopsis:       alchemy ICU is too Au1000 specific
 >
 > The interrupt strings for the au_icu.c (and some of the identifiers,
 > etc.) are really indicative of the specific Au1000 port, and do not
 > reflect the general Alchemy family.
 >
 > This can actually lead to confusing output, e.g. from vmstat -e,
 > because the interrupts are not wired the same on all parts.
 >
 > A better solution, IMO, is to generalize the strings to "irq XX".
 > This provides less information than the current port does, but at
 > least the information is not incorrect!  (And someone familiar with a
 > given board can easily lookup up the IRQ mappings if needed.  And the
 > actual drivers print out the IRQ they are on at attach time, so it
 > should all be good. :-)
 
 The way I'd previously worked around this was to have a table per
 supported CPU type, similar to the way that aubus.c does things.  While
 you can refer back to dmesg for interrupt number assignments, I think
 I prefer to see the irq names in vmstat -e/-i without having to do the
 cross-referencing elsewhere.
 
 I've also been thinking of stripping out tables for each CPU in to their
 own files, and having a way of just configuring support for a single CPU
 type, instead of always being able to support CPUs (and devices) for all
 Alchemy CPU types that exist.  While it's sometimes convenient (eg, I
 don't have to use a different kernel when I turn a different board on
 here and boot with tftp kernel), I think it makes more sense from an
 embededed POV to just support the CPU and features you need.
 
 Cheers,
 Simon.
 --
 Simon Burge                            <simonb@wasabisystems.com>
 NetBSD Support and Service:         http://www.wasabisystems.com/