Re: toolchain/55439: Reduce redudnancy by separating arch and platform

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

The following reply was made to PR toolchain/55439; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/55439: Reduce redudnancy by separating arch and
 platform
Date: Wed, 9 Jun 2021 04:57:43 +0000

 On Tue, Jun 30, 2020 at 11:15:00PM +0000, cmhanson%eschatologist.net@localhost wrote:
  > NetBSD right now treats all of the platforms it supports as
  > architectures, probably for historical reasons. However, there is a
  > large amount of overlap between architectures that could be
  > eliminated if there was more explicit separation.
  >
  > [...]
 
 Indeed.
 
 Things are moving in this direction... slowly... but it turns out that
 surprisingly many distinct userland builds are still needed because of
 endianness, 32 bit vs. 64 bit, incompatible processor ABIs,
 incompatible CPU variants, different FPUs... unfortunately the world
 is a mess.
 
 Folding more of the m68k ports together than currently are is probably
 feasible, but in this case it becomes difficult to test major reorgs,
 and for some of the retrocomputing platforms people get upset if
 anyone proposes "demoting" their favorite port. :-|
 
  > The end result of taking this to its logical conclusion would be to
  > build virtually all of the bits for a particular CPU architecture
  > once, in an entirely generic fashion, including the GENERIC and
  > INSTALL kernels thesmelves and many of the kernel modules. Only
  > modules for platform-specific device drivers and code
  > platform-specific first/second-stage bootstrapping would need to be
  > built for the individual platforms.
 
 For kernels this usually isn't feasible because the kernel startup
 code is heavily platform-dependent (not just architecture-dependent)
 and it's not usually that easy (or even always desirable) to try to
 smooth it over in an extra bootloader stage.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost