In article <44029233.5090404@damore.org>
garrett@damore.org wrote:

> It strikes me that the idea that arc,evbmips,algor,cobalt,hpcmips, etc.
> are all so different as to require different "ports" is a bit bizarre,
> especially when the port includes a large part of software that is *not*
> included in the kernel.
> 
> I.e. why are we building n-different (where n > 6 and growing) different
> copies of userland, that are basically identical except for the results
> returned by uname?

In the perfect world, all ports which have the same ${MACHINE_CPU}
should have the same userland binaries. Actually we've already shared
all X clients and games sets. The only reason why we have different
base.tgz and comp.tgz is that some binaries (disklabel(8), fdisk(8) etc.)
have ${MACHINE} specific #ifdefs, which should be rewritten to use
uname(3) and if/else clauses at runtime.

> Is there some compelling reason why we couldn't have e.g. mips32 as a
> "port", and then have e.g.:
> 
> sys/arch/mips32/alchemy/...
> sys/arch/mips32/cobalt/...
> 
> directories and kernel config files like ALCHEMY, DBAU1550, COBALT, etc.

Some possible reasons are on ${MACHINE} specific part:
- disklabel, which may have some compatibility stuff with the "native" OS
  (OMS400 requires MBR support but current evbmips doesn't have it BTW)
- bootloader binary (depends on the firmware)
- installation note (ditto)
etc.

> We already have something like this within e.g. "evbmips", but it could
> be extended to cover pretty much any R4Kish ports, I'd think.

evb* ports are some exceptions, IMHO.

There is no particular difinition what ${MACHINE} or "port" is,
but in general the "port" means machines which can be covered by
the single GENERIC kernel. I.e. machines whose diffences are
small enough and dependent code can be switched at runtime.
Actually, old arm32 port has been split into three independent
ports, acorn32, cats and shark.

But in this difinition we'll have too much ports even for
a rare single architecture, so evb* ports cover all such machines.

> Is there some compelling reason to keep each port in its own directory
> tree that I don't understand, or are we doing it this way just be cause
> that's the way it has always been done?

For the kernel part, MD directly should have only MD stuff and
all code which can be shared among all mips ports should be in
arch/mips. That's all, I think.

> And if the latter case is true, is there a reason we couldn't/shouldn't
> change it?

It depends how we can handle MD stuff (I could be wrong though).

There are also some historical reasons because NetBSD may be
the first OS which supports machines which have the same cpu
but differnt manufactures.
(mips ports are still better than m68k ports)
---
Izumi Tsutsui