> We now have the infrastructure to allow all the m68k-based ports to use
> a common set of sources.  This is *great*.  However, this also means
> that gcc doesn't predefine a symbol for the local machine type (hp300,
> sun3, amiga, mac68k, da30) any more.  Also, some ports may wish to
> define additional symbols, such as hp9000 for the hp300 port.

we went over this on 'core' the other day, and came up with a complete
set of #defines to use...

basically, for m68k machines it boils down to:
	m68k mc68000 mc68020 __NetBSD__ unix

mc68000 and mc68020 are only there because some braindead programs
use fully-quailified part names, rather than the family name, to
decide what type of cpu they're running on...  (i've never seen
a unix program that used the diffs between an '000, and '020, or an
'030 to change its code output/generation, other than the compiler...)

i can't think of a good reason other than to use *very* architecture
dependent feature (e.g. 'libarch') that programs would need anything
more specific than this.

If they are using libarch, or something that's *that* hardware
dependent, then they *could* just include sys/param.h,
and #if on MACHINE...  (i.e. #if (MACHINE == hp300) ...)

As for kernel compiles, they already define the specific architecture,
so that's not a problem, either.



the long term goal for the 68k machines is to have them look
*exactly* (i.e. 100%) alike from user-land, wherever possible.
i'd even go so far as to venture a guess that, with the exception of
some drivers and the startup code, they could all be identical.

obviously, some things (e.g. graphics ioctls) will change from
port to port, but the rest should stay the consistent.



chris

------------------------------------------------------------------------------