Date: Sat, 27 Apr 2002 17:21:38 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, re@FreeBSD.org Subject: Re: cvs commit: src Makefile Makefile.inc1 src/etc Makefile src/ Message-ID: <20020427142137.GD35685@sunbay.com> In-Reply-To: <XFMail.20020426170559.jhb@FreeBSD.org> References: <20020426203600.GA69757@sunbay.com> <XFMail.20020426170559.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--KdquIMZPjGJQvRdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2002 at 05:05:59PM -0400, John Baldwin wrote: >=20 > On 26-Apr-2002 Ruslan Ermilov wrote: > > On Fri, Apr 26, 2002 at 04:17:27PM -0400, John Baldwin wrote: > >>=20 > >> On 26-Apr-2002 Ruslan Ermilov wrote: > >> > Log: > >> > Milestone #1 in cross-arch make releases. > >>=20 > >> I'm sure re@ or qa@ would have loved to have had a chance to review th= is > >> before > >> it went in. > >>=20 > > Huh? My initial message subjected "Cross-platform releases" was CC:'ed > > to re@FreeBSD as well. None from re@ replied to my message. Is it > > probably a good time for me to apply to join re@? :-) >=20 > The original message didn't include a patch. :) The idea is certainly > something we would like to see, but the details are something your message > did not talk about. >=20 > >> > In release.3 and doMFSKERN, build kernels in the "world" > >> > environment. KERNELS now means "additional" kernels, GENERIC is > >> > always built. > >>=20 > >> This is wrong. Not everyone wants to use GENERIC. Instead, please use > >> the approach of a patch green has worked up that replaces KERNELS with= two > >> variables: > >>=20 > >> DEFAULTKERNEL?=3D GENERIC > >> #EXTRAKERNELS?=3D > >>=20 > >> Where DEFAULTKERNEL is always built and is installed as /boot/kernel/k= ernel > >> on CD's, and in the base dist, etc. EXTRAKERNELS is an optional list > >> similar > >> to what you have done with KERNELS. We should not specifically tie pe= ople > >> to > >> using GENERIC as the default kernel. For people who build custom rele= ases, > >> it > >> should be possible to use a different kernel config besides GENERIC fo= r the > >> default kernel install, yet still include a GENERIC kernel in the rele= ase as > >> a > >> fall-back kernel. > >>=20 > > Probably, but my patch did not make things worse. Old version (before = my > > patch) assumed that GENERIC was always present in KERNELS, and used it = as > > the _main_ kernel: >=20 > I know, and green has already developed and tested a patch as I mentioned= above > which I would have encouraged you to incorporiate if you had asked for re= view.=20 >=20 > >> > Inline createBOOTMFS target. > >>=20 > >> Why? > >> =20 > > Because it's now used only once. I think that calling it in doMFSKERN > > in the old version was an oversight too. >=20 > Well, this should likely have been a separate commit from adding cross-re= lease > support as it's not very related. >=20 > >> > Use already built GENERIC kernel modules to augment mfsfd's > >> > /stand/modules. GC doMODULES as such. > >>=20 > >> This assumes too much about GENERIC, IMO. Eventually we might use a > >> separate > >> kernel config that just builds modules and no actual kernel for this t= ype of > >> stuff. > >>=20 > > The only assumption made is that _all_ modules are built with GENERIC. > > This is always true unless MODULES_OVERRIDE is set (which it apparently > > is not). Moreover, BOOTMFS (for which we create modules) is by design > > a reduced version of GENERIC. >=20 > In the future we will have something much more general than MODULES_OVERR= IDE > and you just wiped out the abstraction in the release makefile that would= let > us more smoothly handle that when it comes. >=20 What you call an abstraction, the doMODULES target? :-) Okay, then I will say I did not wipe it out, but rather _fixed_ it for the current status quo (there's no any real need in rebuilding the GENERIC modules twice nowadays (probably in the future, there will), and just inlined it (because it's a no-op nowadays!). If it will make you happier, I can make it a separate (but empty!) doMODULES target, and call it from the appropriate place in release.8. But I hope you realize that it will better be served when this future arrives. :-) 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 --KdquIMZPjGJQvRdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8yrPxUkv4P6juNwoRArjJAJ9SeTwtVnQd4/1/lksxpO5tdssTHQCdHI37 YOfAPcKDRhzWyiDPUnUcaIg= =lZFW -----END PGP SIGNATURE----- --KdquIMZPjGJQvRdI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020427142137.GD35685>