On 24 Oct 2000 eeh@netbsd.org wrote:

: 	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.

If the kernel is being generated from sys/arch/sparc, it needs to have a
MACHINE of sparc.  This is the same as how the sun3/sun3x merge happened,
which is the prior art Matt cited.  Never mind that the hardware isn't
exactly the same and the locore isn't the same; it isn't on sun3 and sun3x,
but both are now identified as "sun3".

Think about doing a "make build" with objdirs and OBJMACHINE, for instance.  
Exactly what should I expect to find in "obj.sparc64" -- V9 binaries, or "V8
or V9 depending on what kernel I'm running"?  And which kernel directories
should the build use for generating distributions?  Same goes for LKMs,
which are tied to a MACHINE (not a MACHINE_ARCH).  I shouldn't expect to tie
a V9 LKM to a V8[plus] kernel...!

MACHINE should identify the system down to a hardware level, yes.  However,
this merge is claiming that sparc and sparc64, when run in 32-bit mode, have
similar enough hardware to share the same kernel directory.  This implies
that they should report the same value for MACHINE under sys/arch/sparc.
sparc64/sparc64 should only be used for sys/arch/sparc64.

: 	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.

Um, shouldn't an assembler-with-cpp version of locore (and other assembly
files) fix this?  You would then be able to find __sparc_v9__, and not have 
to use that "_LP64" config option.  Of course, there are a couple other
LP64-specific config options making the config files not *exactly* the same
(COMPAT_NETBSD32 and EXEC_ELF64, although the latter could go in
"std.sparc64").

: 	:    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".

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

It's following past patterns so that we don't build a jumble of
inconsistencies.

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