On 20 Oct 2000, Hiroyuki Bessho wrote:

:   After all, this is an endian problem.  if we have evbsh3eb/evbsh3el
: split as you mentioned, dreamcast will happily share source code and
: userland object code with evbsh3el.

First off, endianness is a required split of MACHINE_ARCH.  So we need to
address making MACHINE_ARCH reflect "sh3e[bl]" on proper endianness.  This
does not mean we need a separate directory; the sh3 directory is fine (like
mips for mipse[bl]).

With that said, MACHINE should report differently for different endianness
as well.  However, again, evbsh3 can be the actual source directory for
kernels of evbsh3e[bl], if you want, because the code is identical (only dip
switch settings matter).

:   I feel evbsh3el/evbsh3eb is better than evbsh3/dreamcast.  If we do
: it in that way and build the tree with MACHINE=evbsh3el for dreamcast,
: I'd say the names are bad.  Dreamcast is not an evaluation board.
: sh3_generic_e[bl]? or just sh3e[bl]?

Just sh3e[bl] should not be used as the MACHINE, as these are the
MACHINE_ARCH (CPU)... which is used by more hardware (mmeye).  A port name
needs to exist for the non-CPU hardware.

Rule of thumb:  If you can make a GENERIC kernel that will work on all
hardware within a MACHINE, then those machines can share a port (AND source
directory).  But if peripheral hardware is too different between systems,
making GENERIC too difficult to make, the ports should be separate MACHINEs.
arm32 is splitting because of this reason.

I have a feeling that the dreamcast support will get larger for the special
hardware, while the evbsh3 code will remain fairly static (as the eval
boards do not have as many IO options).  This would suggest--without further
hardware knowledge--that dreamcast should be its own port.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.