It appears to me that <machine/cpu.h> is supposed to define the
"interface" for machine-independent code.  It is not specifically
related to the Central Processing Unit (CPU) as far as I can tell.

It is good software engineering practice to separate interface
definitions from implementation as much as possible.  This has
practical benefits as well:  You can change an implementation as
much as you want, and don't have to recompile the MI code that
uses the interface unless you actually change the interface.

The minimal content of <machine/cpu.h> appears to be:

	cpu_wait()
	struct clockframe
	CLKF_USERMODE()
	CLKF_BASEPRI()
	CLKF_PC()
	CLKF_INTR()
	aston()
	need_resched()
	need_proftick()
	signotify()
	setsoftint()
	setsoftnet()
	setsoftclock()

I tried to follow the "separate interface" model in the sun3 port
by moving all the other stuff that was in cpu.h into other files
(those used only withing arch/sun3).  This has helped me...

Unfortunately, some of the shared m68k code assumes that cpu.h
still contains all the non-interface stuff, causing occasional
problems with the shared code in arch/m68k.  (In particular, the
new copypage.s assumes arch/m68k/include/cpu.h is used, which
contains lots of non-interface stuff...)

The cleanest way, in general, to solve such problems is to use the
model where, for any file xyzzy.c, there is an xyzzy.h header that
defines anything exported by the .c file.  While this is a good
general principle for library-ish things, a larger software base
such as our kenel usually wants an interface definition header file
for each "module."   We can consider things like arch/sun3 as one
implementation of the "cpu" with cpu.h defining the interface.

I'm inclined to suggest that things like sharable drivers (i.e.
sys/dev/*) and sharable code modules (i.e. arch/m68k/*) should
stick to the simpler model, where each individually sharable
module exports a header file describing the interface.  If the
interface also happens to be part of a module interface (i.e.
cpu.h) then the latter should include the needed header.

Finally, here is a specific suggestion in line with the above:

The new functions copypage and zeropage should be declared by
their own header file (i.e. m68k/copypage.h) and should live in
a separate module (i.e. m68k/copypage.s) in order to follow the
"library" model of interface/implementation separation.

Comments?
Gordon