Re: Guidelines for choosing MACHINE & MACHINE_ARCH?

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On 24 June 2015 at 23:38, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> 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.

It's all too confusing.  I'd like to be able to do:

   ./build.sh rpi

but instead I use:

  ./build.sh -... evbarm

and likely build far more than I need.

> [...]
>
> 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".

This probably illustrates why 'cpu' has become so overloaded.

When building userland,  "cpu" identifies:

- a system-call convention for the architecture
- user instruction set architecture (to borrow an IBM term) + calling
convention (application binary interface)
- and?

How do I build a 32-bit LE soft-float Arm9 userland?  Or more more
seriously, how can I build just a arm7hf targeted compiler and user
land?

For the kernel "cpu" means a lot more:

- first, the kernel can adopt its own ISA/ABI (64-bit kernel, 32-bit userland)
- chip-family specific code for dealing with VM and context switches
- other stuff I can't think of

(IBM called this the operating environment architecture).

Perhaps, rather than trying to re-organize the source tree,  the first
step is to look at build.sh.  For instance:

- clarify/simplify the terminology (MACHINE_ARCH / -e seems to be the ISA/ABI)
perhaps "./build.sh -e arm7hf tools sets" builds my arm7hf userland,
it isn't clear

- allow finer grained "machines" or platforms so I can have
"./build.sh -m rpi" do the right thing

Only once the model seems to be working, start looking at the source code.

Andrew

> 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