> > 	Install both sparc and sparc64 kernel header files on all
> > 	machines and build unified kvm grovellers.
> > 
> > The last one sounds easiest, with the most benefits and least risks.
> > 
> > If having a dozen extra files in /usr/include bothers you, you can
> > simply `rm -rf /usr/include/sparc64' (unless you want to build a kvm
> > groveller.)
> 
> 
> The problem is not the presence of the sparc64 header files, but rather
> that the change in arch/Makefile tricks a sparc into starting a build
> of the sparc64 bootblocks.  This wouldn't be too bad, if only that
> build would use the sparc64 headers just installed... (actually, it
> should be including directly from the sparc64 kernel sources).

Didn't notice it caused that to happen.  OTOH if there were no name
conflict between the different bootblocks and installboots this could
be a good thing.

> In general however, I would argue that if a particular MACHINE_ARCH
> family shares userland programs, it should also share a common set
> of header files that are used to build them.  Header files that
> contain MACHINE-specific architecture details should be hidden
> from accidental visibility by not installing them under `/usr/include'

The proc structure and the trapframe structure and the fpu structure
and the regs structure are all machine specific and different between
sparc and sparc64.  The old ones simply do not have enough room for
all the registers in the 64-bit CPU.

> The need for kvm functions to know about different architectures
> can be (I hope...) handled by including a `discriminator' in the
> data structures visible to userland (e.g. kcore.h).

Don't you still need to know the layout of all the structures at
compile time?  And doesn't that require the inclusion of both sets of
header files?

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me