> On Fri, 16 Feb 2001, Jason R Thorpe wrote:
> 
> Having said that I think your proposed directory layout is sane in
> general, here are the few things I'm not sure about:
> 
> > 	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.
> 
> I'm not sure that the differences among ARM6, ARM7, ARM8, ARM9, ARM10, SA1
> and Xscale really warrant a separate directory for each one.  ARMs seem to
> have fairly orthogonal sets of features, and arbitrarily filing code under
> the name of the first CPU to contain the relevant feature seems wrong to
> me.

ARM 6 & 7 are identical from the programmers perspective.  ARM8 I would 
ignore, I personally doubt we will ever see a serious use of that with 
NetBSD.  SA1 is sufficiently different from ARM6 to warrant potentially 
separate support (mainly that the CPU uses write-back caching instead of 
write-through).  This impacts the way the pmap is structured, and could 
justify a different implementation for machines where it is know to be 
only SA (or later) vs earlier chips.  Chips like ARM9/10 SA11x0 have a FCS 
(fast context switch) extension in the MMU.  If you are prepared to 
restrict (all?) processes to 32M of VM, then you can avoid cache flushes 
on a context switch; this also warrants a separate configuration.

Maybe a more sensible arrangement would be by CPU architecture.  Eg armv3 
(for arm6, 7), armv4 (SA1, ARM8), armv4fcs (sa11x0 etc), armv5 (arm9E, 
arm10) ...

R.