[ moved to tech-kern, bcc'd to port-arm32 - I've left a little
  more context in because of that.  Maybe even tech-install and/or
  tech-userlevel should be on the list... ]

Todd Whitesel wrote:

[ in reply to a message from cgd in reply to another message from Todd ]

> > > Okay, so how do I build a sun3 kernel+userland on a next68k box?
> > > Is that a native build??
> > 
> > Right now, in theory (i.e. not having looked into it) if you have to
> > do more than set MACHINE in the environment, there are bugs.  That's
> > how it should work.
> 
> ... and set DESTDIR so you don't accidentally screw over your own installed
> stuff. This starts to grate against the school of thought that says DESTDIR
> should only be used to produce a clean tree for the creation of tarballs. I
> suppose that as long as the host system has already done a non-DESTDIR build
> of its own stuff beforehand, everything should be fine. (Other cross-build
> efforts implicitly require this sort of thing already.)
> 
> > The Right Thing, of course, is to have the user-land programs
> > completely common, i.e. there's no difference at all between a sun3
> > userland and a next68k userland.
> 
> Agreed, but doesn't this beg the question: what's the point of having two
> different ports, if everything outside of sys/ is the same for both of them?
> 
> I guess what I'm really railing against is the fact that we can't build a
> "m68k userland" -- we can only build "sun3 userland" or "mac68k userland".
> Because of this, the build system always has enough information to hack in
> small differences. Proper construction of a sharable userland build demands
> that we elminate port-selection information as an input, and only provide
> the CPU architecture.
> 
> How hard would it be to support MACHINE==m68k ? That would be like having a
> dummy m68k port. Mmmm, port-m68k.

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?

> > Also, actually having too many things shared is just broken.  how many
> > optimization opportunities are missed because of the 'one code fits
> > all' policy there?
> 
> Watch out; that line of reasoning ultimately calls for splitting up Alpha
> so that you can have BWX capable machines versus the older ones.
> 
> > what's the right binary -- you can pick only one -- to install in a
> > NetBSD/arm32 kernel distribution set?
> 
> I already answered this; my answer was "why not drop the requirement for
> a single kern.tgz instead?"  I note that mac68k is a weird case, they have
> kern.tgz and kern_sbc.tgz because unfortunately both kernels are needed
> due to really nasty SCSI problems.
> 
> At the risk of revealing my ignorance about the sys/ tree, I don't see
> how splitting it up is the only way to clean it up. How many radically
> different vax systems are represented in its GENERIC kernel? What about
> nubus vs. PCI powermacs, or PCI vs. TurboChannel Alphas? What are they
> doing right that arm32 _can't_ _possibly_ also do right?

FWIW, simplistically I like to think of each MACHINE type as one range
from a manufacture.  Thus all the vaxes are together, all the alphas are
together, all the sparc-based suns are together.  For arm32, we have
sharks, CATS, etc - these are separate manufactures and model lines with
(probably?) nothing in common except the CPU.

Simon.