I've probably raised this before, but here goes *again*.  Call me
thick.  :-)

It strikes me that amongst the gazillion different mips ports, there are
at least two *basic* classes:

1) mips32
2) mips64

(I'll ignore the older pre-MIPS32 ISAs for now).

It strikes me that the idea that arc,evbmips,algor,cobalt,hpcmips, etc.
are all so different as to require different "ports" is a bit bizarre,
especially when the port includes a large part of software that is *not*
included in the kernel.

I.e. why are we building n-different (where n > 6 and growing) different
copies of userland, that are basically identical except for the results
returned by uname?

Is there some compelling reason why we couldn't have e.g. mips32 as a
"port", and then have e.g.:

sys/arch/mips32/alchemy/...
sys/arch/mips32/cobalt/...

directories and kernel config files like ALCHEMY, DBAU1550, COBALT, etc.

We already have something like this within e.g. "evbmips", but it could
be extended to cover pretty much any R4Kish ports, I'd think.


I'd tend to think such a change would have a couple of immediate impacts:

1) greater code sharing/reuse between various similar mips ports (e.g.
the various xxx_bus_space stuff is pretty darn similar for all ports, as
is the handling of e.g. cpu_intr)
2) a *single* userland code base for all mips32 and for all mips64 boxes
3) an easier to understand directory tree.  (i.e. all 32-bit mips ports
are located underneath a "mips32" tree.)


Is there some compelling reason to keep each port in its own directory
tree that I don't understand, or are we doing it this way just be cause
that's the way it has always been done?

And if the latter case is true, is there a reason we couldn't/shouldn't
change it?

    -- Garrett