Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 May 2003 12:34:23 +0300
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        current@FreeBSD.org
Subject:   Do we want to split release.9 into MD parts now or not?
Message-ID:  <20030520093423.GA62969@sunbay.com>
In-Reply-To: <20030520084749.GA22687@dragon.nuxi.com>
References:  <3EC825C4.6040203@btc.adaptec.com> <20030519024518.05B402A7EA@canning.wemm.org> <20030519061401.GB40604@sunbay.com> <20030519192119.GA4267@dragon.nuxi.com> <20030519193120.GB79469@sunbay.com> <20030519221106.GA17226@dragon.nuxi.com> <20030520044418.GA34212@sunbay.com> <20030520083421.GB22249@dragon.nuxi.com> <20030520084052.GA60294@sunbay.com> <20030520084749.GA22687@dragon.nuxi.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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

[Reattaching current@ as this turns out to be a normal discussion.]

On Tue, May 20, 2003 at 01:47:49AM -0700, David O'Brien wrote:
> On Tue, May 20, 2003 at 11:40:52AM +0300, Ruslan Ermilov wrote:
> > > legacy assumption that every platform has boot floppies.  Yet another=
 way
> > > that release/Makefile needs a *major* over haul.  I'd take that on, b=
ut I
> > > know the resulting argument that would entail.
> >=20
> > I hardly would call the src/release/Makefile,v 1.775 commit as the
> > step in this direction.  ;)
>=20
> Feh.  I call src/release/Makefile,v 1.775 a total step in the right
> direction.  release.9 should be made separate for each platform (I wont
> play these floppy games for AMD64) and then the commonality extracted to
> release.9.common.  We've been in-line ".ifdef" special casing everything
> related to the floppies and CDROM boot image for too long.  We would
> never tolerate that in our C code.
> =20
There are only 5 architecture ifdefs in release.9, let's consider
them all:

>>> .if ${TARGET_ARCH} !=3D "ia64" || ${TARGET_ARCH} =3D=3D ${MACHINE_ARCH}

release.9 for ia64 cannot be currently cross-built -- gpt(8)
is built on ia64 only.  When gpt(8) is unconditionalized,
this may be removed.

>>> .if ${TARGET} =3D=3D "pc98"

We want pccard.conf on pc98.

>>> .if ${TARGET_ARCH} !=3D "ia64"

ia64 doesn't have boot blocks.

>>> .if ${TARGET} =3D=3D "i386"

/boot/mbr only exists on i386.

>>> .if ${TARGET_ARCH} =3D=3D "alpha" && !defined(NO_FLOPPIES)

A bandaid for Alpha kern.flp being low on space (kgzip(1)
support would fix that).

That's all about it; another 80% of release.9 is MI.


There are only 4 architecture ifdefs in doMFSKERN, let's consider
them all:

>>> .if ${TARGET} =3D=3D "i386"

Clearly this is a huge optimization for the space on boot
floppies; the reason this is ifdefed is only because other
arches don't have the support for kgzip(1) at the moment.

>>> .elif ${TARGET_ARCH} =3D=3D "ia64"

ia64 provides the EFI boot loader; there are rumors that
for newer ia32 machines this could also be made a case.

>>> .if ${TARGET_ARCH} !=3D "ia64"

On ia64, we must use ACPI; outstanding ACPI issues don't
allow us to enable it unconditionally for installation
kernels on i386.  I'd rewrite this one to be:

    .if ${TARGET} =3D=3D "i386"

>>> .if ${TARGET_ARCH} =3D=3D "i386" && ${AUTO_KEYBOARD_DETECT}

I have no idea why we need to boot(8) i386 with -P.

Overall, I think that having 9 architecture ifdefs for
the whole boot floppies creation process is allowable,
especially bearing in mind that they are real tiny,
and 3 of them can be considered temporary.

On the contrary, in my opinion splitting release.9 into
MD subtargets would bring a lot more disorder here.

I'd have liked to hear other opinions now (our opinions,
David, we already know ;-).


Cheers,
--=20
Ruslan Ermilov		Sysadmin and DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+yfafUkv4P6juNwoRAoOjAJwM9XM6n0l3YMVDHT6emGjOt7sROgCeJ/GB
/bg8sd+tcAH0+C8FDOMbon8=
=8Pi+
-----END PGP SIGNATURE-----

--fdj2RfSjLxBAspz7--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030520093423.GA62969>