NetBSD Problem Report #55439

From www@netbsd.org  Tue Jun 30 23:14:27 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4E55A1A9217
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 30 Jun 2020 23:14:27 +0000 (UTC)
Message-Id: <20200630231426.345C31A9218@mollari.NetBSD.org>
Date: Tue, 30 Jun 2020 23:14:26 +0000 (UTC)
From: cmhanson@eschatologist.net
Reply-To: cmhanson@eschatologist.net
To: gnats-bugs@NetBSD.org
Subject: Reduce redundancy by separating arch and platform
X-Send-Pr-Version: www-1.0

>Number:         55439
>Category:       toolchain
>Synopsis:       Reduce redundancy by separating arch and platform
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 30 23:15:00 +0000 2020
>Last-Modified:  Mon May 09 23:32:38 +0000 2022
>Originator:     Chris Hanson
>Release:        netbsd-9
>Organization:
>Environment:
N/A
>Description:
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.

As an example, there are a large numer of platforms such as hp300, mac68k, atari, amiga, sun3, x68k, and so on that all use the common m68k CPU architecture. A build of NetBSD for any one of these platforms should consist of building the platform-neutral m68k-architecture components and a separate build of the platform-specific components (such as drivers for unique hardware and first/second-stage bootstrap). A subsequent build of the same NetBSD tree for another one of these same platforms should only build the platform-specific components. And of course the platform-neutral and platform-specific components should be in separate installation sets as well (as should components that are both platform- and architecture-neutral).

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.

It seems like the ARM-based platforms are at least partly doing things now; this would essentially make the strategy explicit and expand it to other platforms.
>How-To-Repeat:
N/A
>Fix:
N/A

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
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 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

>Unformatted:

Home	PR Database Search