Subject: Merged arch/sun3x into arch/sun3
To: None <port-sun3@NetBSD.ORG>
From: Gordon W. Ross <gwr@mc.com>
List: port-sun3
Date: 02/05/1998 00:39:32
Please be advised that I've just merged arch/sun3x
into arch/sun3 so all of arch/sun3x will disappear
the next time you SUP (or it should, anyway).  You
now build both sun3 and sun3x kernels from sources
found in src/sys/arch/sun3 using separate kernel
config files for each.  See for example:
	arch/sun3/conf/GENERIC
	arch/sun3/conf/GENERIC3X

There is a related question that often comes up:
"Why do we need separate kernels for the 3/3X?"

A number of factors add up to conflict:

(1) The sun3x KERNBASE must be an even multiple of (1<<27) due to
    the MMU configuration for (7,6,6,13) VA division.

(2) Changing the sun3x MMU configuration would mean we would lose
    the ability to call PROM functions from the kernel.  We call
    PROM functions for early startup debugging, and reboot, etc.

(3) The sun3 MMU implements only a 28-bit virtual address space,
    and we give the kernel the last 1/8th of that space.

(4) The sun3 MMU does not permit using KERNBASE=0 because it
    can not implement different mappings for supervisor mode
    and user mode; it can only make supervisor mode a subset
    of the user mode mappings.

Therefore, our only choice for common KERNBASE is (1<<27)
which would leave both kernels with an unreasonably small
user virtual space.  It's just not a good trade.

On the other hand, the boot programs are linked to run in
low memory, and as a result we can run the same binaries
on both the sun3 and sun3x.  The latest sun3/stand sources
will run on both machines.  The boot programs now offer a
default kernel name based on the machine name:
	On sun3:  netbsd.sun3
	On sun3x: netbsd.sun3x
This is to allow common boot media.  Of course, it will be
necessary to have a symlink (/netbsd -> /netbsd.sun3). *

* This might change.  Perhaps it would be better to build
  special versions of the boot programs for boot media
  that needs to run on both machines.  Any better ideas?

Regards,
Gordon