Todd Whitesel <toddpw@best.com> writes:
> 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?

not _quite_ everything, i don't think.  the stock 'etc' bits may have
to be different.

boot blocks, etc., will have to be different, but those should be
built/installed on all ports of the same MACHINE_ARCH so in that case
the filesystems will still have the same contents.

The point is, things like bootstrap code is different, things like
MACHINE-specific device support is different, and there's no _reason_
to throw them all together.  Things like X server support will be
different as well.


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

yup.  That's really the point of MACHINE_ARCH, and the long term goal
of its use.


> How hard would it be to support MACHINE==m68k ? That would be like having a
> dummy m68k port. Mmmm, port-m68k.

What would be the point of that?  That's exactly what MACHINE_ARCH is
_for_.


> Heck, I dunno, how can we be sure the build system doesn't have crap
> in it that calls 'uname' instead of using MACHINE? It's a good thing
> we don't call GNU config.guess anywhere, because that's what it does.

uh, huh?  this sounds like a red herring.


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

I don't think i'd like that, because, fundamentally, down to the
bootstrap all of the alphas we support are compatible.

However, there _is_ a strong need for library variants which, for
instance, can provide optimized versions of the libraries for the
BWX-capable machines.


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

In other words, "there's a bug, and the temporary workaround is to
provide two kernel sets."


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

uh, bootstrap compatibility, I think is one...

the split of ports into different MACHINEs is, basically, done along
system family (i.e. hp[34]00, amiga, etc.) lines.  that's just the way
it is.

Believe it or not, all of the vaxen (as far as i'm aware) and all of
the alphas are architected to behave like a single 'family' of
systems.


> Isn't the real problem with arm32 that nobody has figured out how to make
> a GENERIC that really works -- or is it that such a GENERIC would be so
> large that no one wants to run it?

of either, the latter.  but i don't think the answer is either.

such a GENERIC kernel would basically have to cope with:

	* N different bootstrap methods,

	* N different MMU models,

	* N different system busses with not-so-compatible hardware
	  behind them, different interrupt facilities, etc.

there's no real thread tying the code together.  At the very least,
with ports like alpha, you _do_ have a common thread: the architecture
definition, and the information provided by the RPB.

On the ARM, for instance, if you wanted to provide such a common
thread, you'd have to do it in all of your boot blocks... and that's
not even easily possible on some of the systems that the architecture
supports.


> > well, more like mipsel, but direction agrees with what I consider
> > 'right': MACHINE_ARCH common with binaries that interoperate, but
> > different MACHINEs for different system families and non-interoperable
> > kernels.
> 
> But! They're missing out on optimization opportunities, and on hpcmips
> this was explicitly discussed. Ultimately they decided that interoperability
> was more important, because overall, -msoftfloat was not important enough.

I think this may also be an issue of, the existing build system
doesn't include any machinery to do sane 'multilib'-equivalent builds,
which are something you really want and need to do, if you want this
kind of stuff.



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