arch-specific directories

[M. Warner Losh]

In message: <201006141251.45896.jhb at freebsd.org>
            John Baldwin <jhb at FreeBSD.org> writes:
: On Monday 14 June 2010 11:26:45 am mdf at freebsd.org wrote:
: > This is as much as request for information as a suggestion.
: > 
: > I am wondering of the current layout of sys/<arch> make sense given
: > that in several cases the only difference between two "arch" is the
: > bitness, e.g. powerpc and powerpc64.  The 64-bit version supports a
: > few new instructions, but in many cases is the same.  The same issue
: > exists with i386/amd64 but because both have been supported for a long
: > time the have full arch separation.  However, there has been some
: > movement of files that are common between i386 and amd64 into a common
: > x86 directory.
: > 
: > So what I'm wondering is it it makes more sense to have files broken
: > up more like:
: > 
: > sys/<arch>      for common file between bitness
: > sys/<arch>/32
: > sys/<arch>/64  for files that are specific to the bitness
: > 
: > This would presumably serve at least powerpc and i386/amd64 well, and
: > though I don't know for sure I assume at the moment that it works for
: > sun/sparc as well.
: > 
: > So... is this reasonable?  Or does the existence of ia64 throw a
: > monkey wrench into this layout?  Is it not worth the shuffle (though
: > I'd argue that, if we're moving some files to x86 and creating a new
: > powerpc64 that it's better to consider now than later).
: > 
: > I realize there was a discussion earlier along similar lines (the
: > bi-yearly architecture source tree layout discussion) but I don't
: > think it was specifically considering the 32/64 bit differences, which
: > seem to be more common now.
: 
: I think for archs that share a lot in common between 32-bit and 64-bit 
: varieties using shared sources of some sort (e.g. sys/x86) should be 
: encouraged.  This is probably more true (and feasible) for more recently added 
: architectures such as powerpc, arm, and mips.  Alpha and ia64 would not have 
: fit into this category.  Since we do not support 32-bit sparc, sparc64 doesn't 
: really fit into it either.

Having a common directory is a good thing.

: However, I think that some of our build infrastructure assumes that that the 
: current MACHINE/TARGET is in the path, so e.g. make buildkernel uses 
: sys/$TARGET/conf to find the kernel config file to build, so we may be stuck 
: with some of the layout differences at the top-level.  I suspect the arm, 
: powerpc, and mips target names are already embedded at this point, but I would 
: not mind an organization where common code lived in sys/mips and 32-bit and 
: 64-bit bits lived in sys/mips32 and sys/mips64.  (That would work with the 
: existing kernel config path assumptions, but require changing 'arm' -> 
: 'arm32', etc. for MACHINE/TARGET).  I'm sure Warner has some ideas on this 
: topic as well.

MACHINE=arm, but MACHINE_ARCH=arm or armeb.  MACHINE_CPUARCH=arm.

MACHINE specifies the kernel sources.  MACHINE_ARCH is the arch/endian
specification.  MACHINE_CPUARCH is the cpu family.

For mips, all the source is shared between 32-bit and 64-bit
variants for both userland and kernel.

Warner