[This is the wrong place to ask, but i dont hang out on port-m68k,
 so here goes. Feel free to reply to port-m68k and cc: me]

Is there a compelling reason to keep individual copies of the pmap
code for each pmmu/0[346]0-only 68k ports?

We have several m68k-based ports which use only the moto MMU -- the
68851 pmmu or the integrated 030 and 040/060 versions (w/ caching).
At least three of these ports have their own pmap.c and pmap.h, which
are very similar, in some cases almost identical.

The namespace differences are mainly
    <port>_SEG_SIZE
    <port>_STSIZE
    <port>_MAX_PTSIZE
    <port>_ round/trunc page macros

the trunc/round seg macros, and "#if defined(M68060)" for ports which
never got 060 cpus.  adding the 060 ifdefs is harmlerss, and the
namespace-only differences can be handled by creating, say,

      sys/arch/m68k/include/pmmu_pmap.h
      sys/arch/m68k/m68k/pmmu_pmap.c

with canonical pmmu_<foo> versions in pmmu_pmap.h.  Port-specific
<pmap.h> files would include pmmu_pmap.h, provide any truly
port-dependent constants (if any) and rename the m68k_* macros to
the existing port-specific ones, where necessary.

The only place I've noticed where port-specific code is required is
the UVM pmap-initialization, which we could do by passing a vector of
(size, len) pairs to a generic PMMU version; or by duplicating.

Most of the remaining diffs from mac68k, x68k, mvem68k, next68k look
like cruft: leftover HP-mmu ifdefs, inconsistent conversions to
[pv]{size,addr}_t, and similar stuff.

The're a few differences on how writeback cache handling is done on
040/060. Michael Hitch has done the work needed so that we can safely
turn on writeback caching, but I dont understand the existing differences.

Is there a good reason to keep these separate? I dont have any 68k
boxes to test on, but i can do the purely mechanical renaming and
whitespace diffs to get the individual pmap files to converge...