> Chris Gilbert writes:
> > However I believe that arm hardware may have a lot more 
> > in common than other platforms, especially arm26 and arm32 on the RISC-OS 
> > running systems.
> 
> Playing a bit of devils advocate... 
> 
> That seems to assume (and I have no wish to put words in anyones mouth) that 
> most NetBSD+ARM users are running a RISC-OS type machine.  I don't know if 
> that is true.  I, for one, am working with ARM7 & StrongARM class processors 
> in embedded systems (i.e. they don't look anything like a RISC-OS machine).  
> I suspect that with the vast profusion of ARM6, ARM7 & StrongARM based 
> devices out there, that the real future of the NetBSD/ARM port ultimately 
> lies there. 

On this side of the argument I don't think you are going far enough... I 
see the lack of support for ARM7TDMI/ARM9/ARM10 as critical for the future 
life of NetBSD in this area.

> 
> Personally, I find the current fad to divert effort to merge support for 
> arm26 interesting & quaint, but ultimately (for me) irrelevant.  Before one 
> reads too much into that, I *strongly* encourage continued support for the 
> old platforms.  I've got NetBSD/VAX on a VS3100m40, after all. 

With the current source base, supporting ARM26 machines at the userland 
level with one (tiny) change to the ARM32 compilation that has ~0% affect 
on execution performance is an insignificant price to pay for the benefit 
of bringing more developers to the ARM camp.

> 
> Just a thought, but perhaps there needs to be an arm/riscos (or some such) 
> branch for older platforms (are there any non-Acorn arm26 platforms other 
> than the oddball arm26 eval board that I saw on eBay a few months back?), 
> and an arm32 branch for the more modern stuff (say, non-RISC-OS ARM6 and 
> above).  This would be much like the various (6, at least) Motorola 68K or 
> MIPS (5, I think) NetBSD ports that rely heavily on one another for their 
> core kernel functionality (MMU, FP, etc.) and toolchain, but don't make 
> comprimises on peripheral support for their given target.  Hell...there are 
> currently 4 branches for the Hitachi Super-H processor! 

Nobody is suggesting the ARM26 and ARM32 kernels should merge.  It did 
come up briefly, but to the best of my knowledge was rejected because 
(amongst other reasons) the architecture of the pre-arm6 cpus used a 
significantly different MMU architecture (MEMC).

> 
> I wouldn't want things to get this fragmented, however.  I don't think there 
> are enough folks to support more than two branches. 

Most people (everyone) agree that the ARM32 hierarchy is incorrect at 
present, but there is still some disagreement as to what is the best 
fix... should we aim for a single (GENERIC) kernel that will boot on all 
ARM32 machines, perhaps requiring a pre-boot program that hides some of 
the differences, or should we split the ports into separate trees each 
with their own GENERIC kernel?  Personally, given the current size of the 
ARM32 user base, I would be against splitting the trees up.

> 
> That's just my opinion...I could be wrong. 

All opinions are welcome.  Where I've expressed one above is just mine.

Richard.