From owner-cvs-src@FreeBSD.ORG Mon Sep 12 09:16:01 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6453416A41F; Mon, 12 Sep 2005 09:16:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D8B43D48; Mon, 12 Sep 2005 09:16:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 3505746B08; Mon, 12 Sep 2005 05:16:00 -0400 (EDT) Date: Mon, 12 Sep 2005 10:16:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David O'Brien In-Reply-To: <20050912013616.GA78451@dragon.NUXI.org> Message-ID: <20050912094446.P33344@fledge.watson.org> References: <200509071006.j87A6E8s012380@repoman.freebsd.org> <20050911222701.W33344@fledge.watson.org> <20050912013616.GA78451@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_tc.c src/sys/net rtsock.c src/sys/netipx ipx_proto.c src/sys/netnatm natm_proto.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2005 09:16:01 -0000 On Sun, 11 Sep 2005, David O'Brien wrote: > On Sun, Sep 11, 2005 at 10:29:16PM +0100, Robert Watson wrote: >> On Wed, 7 Sep 2005, David E. O'Brien wrote: >>> Modified files: >>> sys/kern kern_tc.c >>> sys/net rtsock.c >>> sys/netipx ipx_proto.c >>> sys/netnatm natm_proto.c >>> Log: >>> Forward declaring static variables as extern is invalid ISO-C. Now that >>> GCC can properly handle forward static declarations, do this properly. >> >> As a result of this change, it is no longer possible to build 7.x kernels >> on 6.x worlds without building all of world or tweaking kernel makefiles. > > We do not support building a HEAD kernel on a RELENG_ box. Never have. > That it usually works for you is just gravy. Or, an alternative viewpoint suggests that the fact that it works for me is what makes it possible to develop on a dozen branches at a time, rather than constantly stumbling over build problems. I.e., I don't really care if it's supported, I just want it to work. I accept that things like C99 support won't ever reach 4.x, so 4.x is no longer a viable build platform for active development, but using the current notion of -STABLE as a build platform is very useful. And by allowing, where possible, a uniform set of build tools we greatly reduce the daily administrative overhead for developers. Breakage can't be avoided if we have progress, but it can be minimized. It's a lot easier for me if you can tell me "Update your build box to the latest RELENG_6" than "As of today, for a relatively minor syntax tweak in the compiler in HEAD but not STABLE, you need to maintain separate build chains for all your development trees". See below for details. > Building a HEAD kernel on RELENG_ isn't anywhere near a supported > configuration. I really don't know where you got the idea it was. On a > 6.0-beta2 machine I just did a HEAD 'make kernel-toolchain' - it took > 3m53.49s and allowed me to build a HEAD kernel just fine. Supposing for a moment that I didn't work for a large CPU manafacturor, but instead had a moderately well-configured desktop system, and that instead of having one source tree I worked on, I were a kernel developer who had 12 active development branches with various kernels, then the math settles out a little differently. On my desktop (P4 1.8GHz, 512MB), it takes 15 minutes per kernel tools build, which assuming I built them on the three machines sequentially, would result in spending 9 hours rebuilding kernel tools as a result of introducing dependencies on compiler tweaks before merging them. In practice, I would hopefully parallelize the builds across all the machines once I discovered that my feet had been shot at, meaning no less than three hours per machine. However, I now also have the following additional administrative hassles: I have to separately manage a build chain source tree for each branch, rather than just a kernel source tree, I have to fault the changes in, trip over build problems, and so on. Which means I also need to decide what components I will need in order to rebuild the kernel toolchains, which presumably means managing the merging of parts of share, src/gnu, the top of tree Makefiles, and countless other things. So the difference between it working may be gravy to you, but it's the difference between spending several days of my FreeBSD time chasing build tool changes over a dozen branches and several machines and spending those days doing productive work. Which isn't to say that progress shouldn't happen, just that a minor change in the order of commits would have saved me a lot of time. >> In the future, could you merge the gcc fixes to the relevant branches >> before merging the dependent C changes, in order to avoid this sort of >> thing? > > I'm afraid that is unreasonable to do in this case. I'd be waiting an > undetermined amount of time for RELENG_6 to thaw before I could do this > work. HEAD was already frozen for 1 months this year - you're > effectively asking me to work as if is frozen for an additional 2 > months. On top of that - the "relevant branches" is HEAD and only HEAD. > Which is where the GCC fixes were committed before depending on them. Just because you don't know how to request MFC's from the release engineering team, which typically has a turn around time of less than a day, doesn't mean I shouldn't expect you to know how to do it :-). > Note that I did the RELENG_5 MFC for you personally, knowing you do try > to build HEAD kernels on RELENG_*. I would have MFC'ed to RELENG_6 for > your benefit, but its frozen. You are an RE - please feel free to MFC > the bug fix. I certainly would not mind. :-) In case you missed it over the last few years, as a developer you are not helpless in supporting the release engineering team by ordering your commits usefully and participating in the MFC process rather than spouting "Let the RE team take care of it". Right now, the expectation is that developers will drive the merging of their commits because they are most familiar with the need to merge the changes, how long the changes will take to settle out, and so on. This is also much preferable to later recriminations of "I didn't want that change merged!". I agree we don't want our end users to build using old toolchains, and therefore don't want to support it, and that it won't always be possible to make it work (i.e., major gcc upgrade in HEAD that doesn't make it to STABLE for two years due to a delayed 5.x release cycle), but when it's trivial to make it work and saves everyone a lot of trouble, it seems like it would be worth it. Robert N M Watson