On Fri, Feb 16, 2001 at 09:40:53PM +0100, Reinoud Zandijk wrote:

 > As Jason suggested a sys/arch/acorn would be a good idea; they all look
 > alike and can share stuff. But technically they aren't all acorns though
 > :) is the Imago a really new port or a variant on the Acorn theme?
 > 
 > That would bring it down to :
 >   arch/arm          <- for common code
 >   arch/acorn        <- for RiscPC, A310/A410,A5000, A7000, RC7500, ....
 >   arch/hpcarm ?     <- iPAQ, eval boards and other hand held devices?
 >   arch/armisapci    <- for ARM boards using only std. PC pheriphals using
 >                        ISA/PCI like CATS, EBSA, DNARD, ....

Nonono.  You seem to be completely missing the point.

armisapci is completely nonsensical.  You lump CATS/EBSA/DNARD in there.
DNARD is fundamentally incompatible with EBSA.  They could not, and should
not, be reasonably in the same "port".

Let's take it from the top...

We support several ARM CPUs and ARM CPU core logic.  That stuff should
go into sys/arch/arm/.  Stuff that is CPU model specific should go
into a subdirectory of that directory.  E.g.:

	arch/arm/arm	<- contains stuff that works on all ARM CPUs
	arch/arm/arm2	<- contains e.g. the ARM2 pmap module
	arch/arm/arm6	<- contains e.g. the ARM6 pmap module,
			   cache routines, TLB routines, etc.
	arch/arm/arm7	<- contains all the ARM7-specific goo.
	arch/arm/arm8	<- contains all the ARM8-specific goo.
	arch/arm/sa110	<- contains e.g. the SA110 cache routines,
			   TLB routines, etc.
	arch/arm/sa11x0	<- contains all the SA11x0-specific goo,
			   including drivers for the on-chip
			   devices.
	arch/arm/ebsa285 <- Support for the '285 core logic, etc.
			    Note that "EBSA285" is really just an
			    ARM-specific board architecture, but
			    doesn't define e.g. firmware.
	arch/arm/ofw	<- Support for the ARM bindings for
			   OpenFirmware (i.e. the calling
			   convention that is defined by the
			   IEEE OpenFirmare ARM supplement, etc.).

	arch/acorn26	<- port to the A310/A410/A5000 (did I get
			   those right?)  Totally different memory
			   management architecture than the later
			   Acorn machines, tend to have small memory,
			   don't want to bog it down with the other
			   stuff in a GENERIC that supported the 32-bit
			   machines.

	arch/acorn32	<- port to the RiscPC and A7000 (looks like
			   the RiscPC and A7000 could boot the same
			   kernel?  Is that true?  If so, why are
			   there separate kernels for them in the
			   current arm32 port?)

	arch/cats	<- port to the CATS and any other EBSA285
			   that uses the Cyclone firmware.

	arch/dnard	<- port to the DNARD platform, including the
			   DNARD-specific devices.

	dev/acorn/iomd	<- Driver for the IOMD and IOMD attachments of
			   other devices.

	dev/acorn/vidc	<- Driver for the VIDC and the WSCONS glue for it.

...etc.  The way we currently treat all these VERY DIFFERENT platforms
as the same is really wrong-headed.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>