Re: Guidelines for choosing MACHINE & MACHINE_ARCH?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Jun 24, 2015 at 04:01:24PM -0700, Matt Thomas wrote:

 > > I agree that evb* is confusing and increasingly meaningless and
 > > would like to see us transition away from it.
 > 
 > I contend that moving to sys/arch/<cpu> is incorrect which there
 > are multiple MACHINE values for that CPU.  sys/tem/mips (haha!) or
 > sys/platform/mips (yuk) or sys/arch/<cpu>sys or something better.

Setting up a scheme with two sets of names is hard. I say this from
the point of view of having set up many research kernel trees and
having tried several times to sort this out in an aesthetically
pleasing way... there are a lot of things that don't fit tidily into
such a model. One of the more vexing problems: what do you call the
"platform" for x86? There are lots of things you *can* call it,
ranging from "generic" to "peecee", but they're all either confusing
or wanky.

Also, there's the potential complication of platforms that are the
same except for the CPU plugged into them; we already have a bit of
this with hpcarm/hpcmips/hpcsh, but it could get quite a bit worse,
e.g. an emulator that has switchable cpu modules but otherwise has all
exactly the same stuff in it.

I eventually concluded that the way it's done in netbsd (one set of
names, with semantics varying as needed) was the best available
choice.

That said, given the ability to have multiple userland builds for a
given "port", which is more or less necessary now with all the arm
variants, there's no real reason to have more than one "port" per cpu
type. One of the traditional criteria was whether you needed a
different kernel; but nowadays having different configs (as evbarm
does) is good enough. Similarly, even if you need a different
bootloader we should be able to sort that out without having a whole
separate "port".

So in the long run I'd say it should just go by cpu type. But as
mashing together e.g. everything in sys/arch/arm and everything in
sys/arch/evbarm would add a lot of entropy, I think we need a stronger
model for the substructure of these directories than we currently
have.

(Also, I think MD stuff should be distributed around the tree more; we
should e.g. keep MD virtual memory stuff in sys/uvm/arch. And we
should keep MD system call stuff in sys/syscall/arch or something like
that, although this first requires splitting sys/syscall out of
sys/kern. Splitting things up this way requires some attention to
MD-level interfaces between subsystems; but having gone through that
with a research kernel I'd say it's beneficial.)

all this is moot when we can't cvs rename though...

-- 
David A. Holland
dholland%netbsd.org@localhost