Subject: Re: Split or don't split arm32?
To: Matt Thomas <matt@3am-software.com>
From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
List: port-arm32
Date: 12/21/2000 12:00:46
--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 19, 2000 at 09:18:47PM -0800, Matt Thomas wrote:
> At one point in time, it was discussed that the arm32 port
> should be split into 3 separate ports: dnard (shark), cats,
> and riscpc (acorn?).
>=20
> This would the common arm32 code and headers in arch/arm32
> but move the "port" specific to their respective directives.
>=20
> The reason I'm asking is another arm32 based will be coming
> to the repository soon and I'd like to do any split before
> I committing for it (or figure out how to glue it into arm32).

May I ask a different question:

* sharing more source code between arm26 and arm32 seems good to me.
* modularizing source code, so that you don't get lost in nested #ifdefs
  when changing the kernel, seems good to me.

But why do we need to split ports? The result is that we have to build
the distribution N times, while 90% of that code is shared. Where 90% is:

- the MI kernel code.
- most of the CPU specific kernel code

It would be more wise, IMHO, to work on the installation process so that
it installs the right kernel for the target machine, the right booter, and
the right /etc/ttys (actually, if only Shark had wscons...)

This way we could build all of the arm32-$X distributions in one run, using
the fastest machine available (be it a Shark/EBSA/other-Strongarm with fast
disk, or a fast Alpha/PentiumV with a cross toolchain).

Whoever wants to split ports even more should device a release building
process that allows reusing the 90% objects already build on, say, some
Strongarm build slave for building the, say, RiscPC kernel and install medi=
a.

The m68k folks will be very thankful, too.

Regards,
	-is

--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAgUBOkHi2jCn4om+4LhpAQHmjwgAgF0QGXImayD7gsRUHd2aPV6LzPS2srpJ
fPSGa792843yMtX7f0gJgA8bajm2kL4fnkrJgAW7Cfc7izESIRGaniksV2GkquHp
Mdn6d7xk6BodqXi31yda+cOIXRMiTqw+ImYZi8yFf7eZz/etVSFvEFxX0HWemreH
c57N0hepceN4+fPeRTbdml164MBQU1Cn9M6HPC3I73w13vBCM8tBteLIzMsdqqQC
QtuG7gH+GDxwD2OB4HQkvOuMA/UUBhjy5ck1Th/WT+wkJwMDq3m9O7b2bJ2EdVtK
E6fy1o4kuA5ovgbSg9Jzos6a0rYpcZM2Z995jVf1ROI/ZipmDNKuGg==
=FEM5
-----END PGP SIGNATURE-----

--NzB8fVQJ5HfG6fxh--