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
rwatson at FreeBSD.org
Mon Sep 12 02:16:01 PDT 2005
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
>>> 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
> 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
> 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
More information about the cvs-src