Simon Burge <simonb@netbsd.org> writes:
> [ ... ]
> 
> I like your idea of one userland per MACHINE_ARCH.  I believe the main
> stumbling block at the moment is the maximum partitions per disklabel
> (and affected programs like disklabel) - anything else?

From the way you quote this, it sounds like you're attributing this
idea to Todd.  That's hardly the case: it's the way things were
intended since day one when MACHINE_ARCH was done.

* For disklabel, it's not just 'maximum number of partitions', it's also
location.  There's also the notion of native label formats.

* things like bus_space type sizes, and other userland-visible type
sizes, have to be kept consistent across different members of
MACHINE_ARCH.

* MD vm and structure sizes also have to be kept consistent, or have
to be special-cased in code that uses them (e.g. kvm).


I've been contemplating for a couple of years how to do this, more in
the last few days.  This also gets wrapped up in arch vs. cpu stuff,
and how you get your headers.

The way i'm current thinking might make sense is:

	* have common headers and code for a given MACHINE_ARCH in
	  in sys/cpu/$(MACHINE_ARH) or similar, as e.g. sys/arch/m68k
	  and sys/arch/mips are now, except _more_ stuff.

	  in it, provide things like MACHINE_ARCH MACHINE-independent
	  types structures and definitions.

	* install those headers into /usr/include, as well as the
	  headers for all MACHINEs of the given MACHINE_ARCH.

	  (probably need to have make variables for that, e.g.
	  MACHINES_m68k or something.  also, we need to have the
	  notion of CPU_${MACHINE_ARCH}, to generically do e.g.
	  the MACHINE_ARCH=mipsel -> CPU=mips translation, rather than
	  whacking it in all of the makefiles all over the source tree
	  where needed.)
	  
	* for the /usr/include/machine symlink, point to the _generic
	  cpu_ headers, and see what breaks.  everything that breaks
	  is either:

		* something that is but doesn't need to be MACHINE
		  dependent, or,

		* something that needs to have code written, so it
		  will be properly decided at run-time based on the
		  MACHINE value.


by decided at run-time, i mean use sysctl (or whatever) to find our
the current MACHINE type, then pick from separately-compiled
machine-specific versions of code, and do the right thing with a
function switch or whatever.

Somebody who's got time and machines to actually test this on should
look into it.  I think mips and m68k are the best first candidates to
test it on.


> FWIW, simplistically I like to think of each MACHINE type as one range
> from a manufacture.  Thus all the vaxes are together, all the alphas are
> together, all the sparc-based suns are together.  For arm32, we have
> sharks, CATS, etc - these are separate manufactures and model lines with
> (probably?) nothing in common except the CPU.

Well, come of them may have common hardware other than just the CPU,
because of standard components.  However, this is _exactly_ the point
of the notion of MACHINE.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.