Then we're looking at something like sun3 and sun3x in their current state,
	which is OK.  However, the one compiled from sparc/conf/GENERIC-ULTRA, or
	whatever its name will be, should identify its MACHINE and MACHINE_ARCH as
	"sparc", since it's really pretending to do an entirely 32-bit dance (and
	its native userland is also 32-bit).

No, MACHINE should be sparc64 since that's what the hardware is and that's
the kernel binary it's running.  You can't run a sparc kernel on a sparc v9
processor.  The trap models are completly incompatible.  However, MACHINE_ARCH
should be sparc.  Which is precisely what the current 32-bit kernels do.

	:    obliterating sys/arch/sparc64/conf/GENERIC32 (which you seem to have planned
	: 
	: actaully, this is so that we can maintain a single file and be able to build
	: both 32-bit & 64-bit kernels.  conf/GENERIC .includes this file and then adds
	: the 3 options necessary for 64 bit kernels.

	Hm.  Perhaps this might be better done (using the split layout) with an
	"update" target in the sparc64/conf/Makefile, which simply pulls the 32-bit
	file, adds the options, so that it can be committed.  You then end up with
	identical files, which can be copied and edited separately as different
	types of machines.

The primary reason we have split include files is that it is impossible to
determine from the make file whether you're using a 32-bit or 64-bit compiler.
This information needs to be passed to the assembly routines so they know
what the memory model and calling convention is.  In theory you could build
the same exact kernel from the same config file with two different toolchains
(or compiler options) and get a 32-bit and a 64-bit kernel.

	:    already).  All you will have left in sys/arch/sparc64 is a "conf" directory
	:    with "GENERIC", a full LP64 kernel that identifies itself as "sparc64".
	: 
	: actually, i don't mind this all that much.

	Well, `let's do it.'  :)

O.K.  But it does seem a bit silly.

Eduardo