Simon Burge <simonb@netbsd.org> writes:
> > * 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 dunno.  USRSTACK may be one thing, but it's not the only thing.

considering, for instance, m68k: how many different MMUs were there,
and how many of them have slightly different sets of information that
needs to be understood by something?  (to exclude things like the sun3
MMU, which are just a different thing entirely.  8-)

(the fact that there are already 4 .c files in libkvm relating to m68k
says that though USRSTACK might be an issue, it's not the only one.
8-)


> Something like (no guarantee of correctness ;) :

If people like those names, sure.  ("I suck at names.")


> 	ARCHDIRS.mipseb=mips    arc hpcmips newsmips pmax
> 	ARCHDIRS.mipsel=${ARCHDIRS.mipseb}

as others have noted, i don't think it's this easy.  8-)


> 	ARCHDIRS.sparc= sparc   sparc64
> 	ARCHDIRS.sparc64=${ARCHDIRS.sparc}

similarly here.  i don't think sparc should include sparc64.  maybe
sparc64 including sparc is OK -- i dunno, but even that doesn't seem
to make much sense to me.  the only thing that should be included
multiple times are the basic CPU support dirs which support multiple
endiannesses (e.g. mips).

(as an aside, i've kinda wondered: why can't sparc and sparc64 be put
in the same MACHINE_ARCH, in the same way that all of the various MIPS
flavors are.  there's similar variation between mips32 and mip64,
right?  I'd expect the same ABI issues to show up in each place, and
i'd expect a consistent solution, but my expectations aren't often in
sync with reality.  8-)


> in <bsd.own.mk> doesn't seem too bad.  Then things like sys/arch/Makefile
> just have
> 
> 	SUBDIR=	${MACHINE_ARCH_DIRS}

yah.


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

*chuckle*  see PR 1781.  no, i don't think it's a good idea.

i don't think it's a particularly good idea here, either, if you're
(jokingly) suggesting the 'machine' automatically repoint itself.
there's too much ability to accidentally make binaries
MACHINE-dependent that way.


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

right, except, you can't really have a single large case statement and
just do everything in one file per MACHINE_ARCH, because, at least
right now, the constant names conflict.  now, you could certaily fix
that...



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