From owner-cvs-all Fri Apr 26 14: 7: 8 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 78B3D37B41D for ; Fri, 26 Apr 2002 14:06:53 -0700 (PDT) Received: (qmail 32423 invoked from network); 26 Apr 2002 21:06:52 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Apr 2002 21:06:52 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g3QL6ov15667; Fri, 26 Apr 2002 17:06:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020426203600.GA69757@sunbay.com> Date: Fri, 26 Apr 2002 17:05:59 -0400 (EDT) From: John Baldwin To: Ruslan Ermilov Subject: Re: cvs commit: src Makefile Makefile.inc1 src/etc Makefile src/ Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, re@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 26-Apr-2002 Ruslan Ermilov wrote: > On Fri, Apr 26, 2002 at 04:17:27PM -0400, John Baldwin wrote: >> >> On 26-Apr-2002 Ruslan Ermilov wrote: >> > Log: >> > Milestone #1 in cross-arch make releases. >> >> I'm sure re@ or qa@ would have loved to have had a chance to review this >> before >> it went in. >> > 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@? :-) 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. >> > In release.3 and doMFSKERN, build kernels in the "world" >> > environment. KERNELS now means "additional" kernels, GENERIC is >> > always built. >> >> 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: >> >> DEFAULTKERNEL?= GENERIC >> #EXTRAKERNELS?= >> >> Where DEFAULTKERNEL is always built and is installed as /boot/kernel/kernel >> 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 people >> to >> using GENERIC as the default kernel. For people who build custom releases, >> it >> should be possible to use a different kernel config besides GENERIC for the >> default kernel install, yet still include a GENERIC kernel in the release as >> a >> fall-back kernel. >> > 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: 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 review. >> > Inline createBOOTMFS target. >> >> Why? >> > Because it's now used only once. I think that calling it in doMFSKERN > in the old version was an oversight too. Well, this should likely have been a separate commit from adding cross-release support as it's not very related. >> > Use already built GENERIC kernel modules to augment mfsfd's >> > /stand/modules. GC doMODULES as such. >> >> 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 type of >> stuff. >> > 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. In the future we will have something much more general than MODULES_OVERRIDE and you just wiped out the abstraction in the release makefile that would let us more smoothly handle that when it comes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message