Chris G. Demetriou wrote:

> 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.

Sorry for the confusion - I guess I should have said something more
along the lines of "I like your renewed push for one userland per
MACHINE_ARCH".

> * 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).

Is it USRSTACK that always gets a mention here?  I would naively guess
that this shouldn't be too hard to sysctl.

> 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.)

Something like (no guarantee of correctness ;) :

	ARCHDIRS.alpha= alpha
	ARCHDIRS.arm32= arm32
	ARCHDIRS.i386=  i386
	ARCHDIRS.m68k=  m68k    amiga atari hp300 luna68k mac68k mvme68k \
				news68k next68k sun3 x68k
	ARCHDIRS.mipseb=mips    arc hpcmips newsmips pmax
	ARCHDIRS.mipsel=${ARCHDIRS.mipseb}
	ARCHDIRS.ns32k= pc532
	ARCHDIRS.ppc=   powerpc bebox macppc ofppc
	ARCHDIRS.sh3=   sh3     evbsh3 mmeye
	ARCHDIRS.sparc= sparc   sparc64
	ARCHDIRS.sparc64=${ARCHDIRS.sparc}
	ARCHDIRS.vax=   vax

	MACHINE_ARCH_DIRS= ${ARCHDIRS.${MACHINE_ARCH}}

in <bsd.own.mk> doesn't seem too bad.  Then things like sys/arch/Makefile
just have

	SUBDIR=	${MACHINE_ARCH_DIRS}

> 	* 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.

Almost sounds like a case for domain-os like symlinks :-)

> 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.

I can see programs like disklabel becoming a bit of a nightmare with
.../disklabel/arch/m68k/machdep.c having large case statements.  It
would however probably be a Big Step In The Right Direction...

> 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.

Todd? :-)

Simon.