--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 21, 2000 at 11:16:01PM -0800, Chuck Silvers wrote:
> I'm with Ig on this issue, I think we should fix the problems with merged
> ports rather than give up on that idea and split up the merged ports.

I'm not completely opposed, but if this split happens, the building
environment should be enhanced so that installation media only can be (at
least semi-, that is on the same MACHINE_ARCH) cross-built.

> one of the guiding princples that we're all supposed to be following when
> working on NetBSD is that we should make code as common as possible.
> it seems to me that any two pieces of hardware that can run the same
> userland binaries should be in the same "port".  (that still leaves the
> question of chips like the MIPS that can run both big- and little-endian,
> but let's leave that aside for the moment.)
>=20
> so what are the implications of this?  there should only be one "port"
> for all the m68k platforms.  "but they can't share kernels!" you say.
> I think the way this was handled for sun3 vs. sun3x is a good example
> of how to start to address this.  put them in the same directory under ar=
ch,
> and use config options to select which set of incompatible hardware suppo=
rt
> you want in a given kernel.  as time goes on, more code can be made
> common and moved into the shared directory for that type of cpu.
> so the way I see this turning into a directory structure is:
>=20
> sys
> 	arch
> 		m68k
> 			m68k
> 			amiga

Pleasenot. You're aware that we're preparing an amigappc port?
Same devices (with the exception of system clock, of course) as Amiga86k,
but different bootloader and different userland and different pmap?

(There's also NewsMIPS vs. News68k, but I don't know how similar those are.)

I think it is more useful to do:

sys
	cpu
		m68k
		powerpc
		arm
			common
			arm32
			arm26
	arch
		amiga(68k)
		amigappc
	=09

And maybe provide build tools that allow to create installation media more
easily.

It might or might not be useful to split machines accross port maintainers.
It surely is of little use to have a split-off port with nobody to actively
maintain it.

Regards,
	-is

--5vNYLRcllDrimb99
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQEVAgUBOkNLPDCn4om+4LhpAQHYLwf/awJVG2zpkhhoenWkXUSdgvVRaOPjxu2I
0u9GHFKDvBNl+yRWS7YDc2QAABPUHWnCyIIi4XDQzYmlqUOpcJSB7WxbgmjN+VoM
lVzrVKc8xg6tP5rf6vBuM+dzgw2gjBbkc+RiwFY26DDvUU+v8pqt9ar8svIS+ttu
TvdTaQI7D7pX1AThQoCUsceWx5GXMyOk73thYLMpjCaBin44d6+Np+C3e2ERXLlw
pkKpEO7RDxANJb8BYGeh5XMahtcGLbOUNOixdz+EfpnN0/HQwS/bYffOo+1hsakU
W5Jy19M010A4sJe6izYRHVkDwKUJITJ2FpuTczhx/kbwJ4R+FhE2mg==
=tDJe
-----END PGP SIGNATURE-----

--5vNYLRcllDrimb99--