In article <199511282337.RAA14202@solutions.solon.com>,
Peter Seebach  <seebs@solon.com> wrote:
> It seems to be a SMOP to provide hooks for an "only '030" or "only '040"
> kernel, which does not do this.
[...]
> Any suggestions, or reasons this option would be bad?  My assupmtion
> would be that the current code would survive, but would be dependant
> on both M68040 and M68030 beinf defined for.

How about something like this approach? Change all tests to use the
macro cpu040 as the conditional, and define cpu040 this way:
(change DO_040 and DO_OTHER to whatever)

#if defined(DO_040) && defined(DO_OTHER)
#define cpu040	(cputype & AFF_68040)  /* or whatever */
#else
#if defined(DO_040)
#define	cpu040	(1)
#endif
#if defined(DO_OTHER)
#define	cpu040	(0)
#endif
#endif

Then the compiler should completely optimize out the irrelevant code if
only one is defined.

As a side note, it seems like it would be a good idea to merge the
common parts of all the Moto pmaps (ie, all m68k ports except sun3 and
maybe hp300) under /sys/arch/m68k. It would save work in the long run, I
think. It would also be nice to have some way to allow for things like a
sun3 GENERIC kernel that supported both sun3 (sun mmu) and sun3x (moto
mmu). Perhaps the generic m68k pmap could have all the functions
prefixed with moto_pmap_, and start at the top with:

#include <machine/something.h>

#ifndef MULTI_MMU
#define moto_pmap_func1	pmap_func1
#define moto_pmap_func2	pmap_func2
...
#endif

sun3/sunpmap.c would likewise start with

#include <machine/something.h>

#ifndef MULTI_MMU
#define sun_pmap_func1	pmap_func1
#define sun_pmap_func2	pmap_func2
...
#endif

Then machine/something.h on the sun3 would contain:

#if (test for supporting both sun3 and sun3x)
#define MULTI_MMU
#endif


and sun3/pmap.c would look all be wrapped in #ifdef MULTI_MMU,
and would contain wrappers that would check for MMU type and call
moto_pmap_xxx() or sun_pmap_xxx() as appropriate.