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

Robert Watson rwatson at
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
>>> 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 

> 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

More information about the cvs-src mailing list