NIC Questions for 6.1 Release - Obtaining changes not in RELEASE

[Chris]

On Sep 13, 2006, at 4:03 AM, Alex Zbyslaw wrote:

>>
>>> Chris wrote:
>>>
>>>> Is there any single source where one can go  to see what has  
>>>> been  changed on the various components of the OS.
>>>
>>> Go to the source :-)
>>>
>>> http://www.freebsd.org/cgi/cvsweb.cgi/
>>>
>> Wow! That's an excellent resource and the bge driver does have   
>> numerous changes that all dance around or on the ...
>> Based on the 6.1-RELEASE-p6 AMD64 system I did yesterday (a  
>> different  server), I didn't see any of these changes on the  
>> source date for  if_bge.c. I'm guessing this has to do with how I  
>> cvsup and the fact  that I remain tracking only 6.1-RELEASE. I used:
>>
>> *default release=cvs tag=RELENG_6_1
>>
>> in the supfile and these changes are not pulled under that tag.  
>> How  does one approach that, set the tag to RELENG_6 which does  
>> grab  these. From the handbook it seems to recommend not moving  
>> forward  from a "RELEASE" for a production type of implementation.  
>> How does  one grab specific changes to a driver without actually  
>> cvsupping to  that entire revision or am I missing something  
>> really basic and I  should be using the RELENG_6 tag for my  
>> production servers? It really  looks like that's the version of  
>> the bge driver I should be using.
>
> If you click on if_bge.c (which I guess you did to see all the  
> comments), you'll see above each comment a "Branch: " which tells  
> you where the changes have been committed.  E.g.
>
>> Revision *1.91.2.17* <http://www.freebsd.org/cgi/cvsweb.cgi/src/ 
>> sys/dev/bge/if_bge.c?rev=1.91.2.17&content-type=text/x-cvsweb- 
>> markup> / (*download* <http://www.freebsd.org/cgi/cvsweb.cgi/% 
>> 7Echeckout%7E/src/sys/dev/bge/if_bge.c?rev=1.91.2.17&content- 
>> type=text/plain>) - annotate <http://www.freebsd.org/cgi/ 
>> cvsweb.cgi/src/sys/dev/bge/if_bge.c?annotate=1.91.2.17> - [select  
>> for diffs] <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/ 
>> if_bge.c?r1=1.91.2.17>, /Thu Sep 7 08:49:10 2006 UTC/ (6 days, 2  
>> hours ago) by /oleg/
>> Branch: *RELENG_6 <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ 
>> dev/bge/if_bge.c?only_with_tag=RELENG_6> *
>> Changes since *1.91.2.16: +24 -5 lines*
>> Diff to previous 1.91.2.16 <http://www.freebsd.org/cgi/cvsweb.cgi/ 
>> src/sys/dev/bge/if_bge.c.diff?r1=1.91.2.16&r2=1.91.2.17> (colored  
>> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/ 
>> if_bge.c.diff?r1=1.91.2.16&r2=1.91.2.17&f=h>) to branchpoint 1.91  
>> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/ 
>> if_bge.c.diff?r1=1.91&r2=1.91.2.17> (colored <http:// 
>> www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff? 
>> r1=1.91&r2=1.91.2.17&f=h>) next main 1.92 <http://www.freebsd.org/ 
>> cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.92&r2=1.91.2.17>  
>> (colored <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/ 
>> if_bge.c.diff?r1=1.92&r2=1.91.2.17&f=h>)
>>
>> MFC rev. 1.140
>> Properly lock ifmedia callbacks. This should prevent concurrent  
>> access to PHY.
>> Following issues should be resolved:
>> - random watchdog timeouts (caused by concurrent phy access)
>> - some link state issues
>> - non working TX if media type was set explicitly
>>
>> PR:		kern/98738 <http://www.FreeBSD.org/cgi/query-pr.cgi?pr=98738>
>>
> which looks like one you'd want!  You'll see the tag is RELENG_6 so  
> yes you will need to cvsup to this (aka 6-STABLE) to get those  
> changes.  Presumably the changes will make it to 6.2-RELEASE, so  
> you could switch to tracking that when it comes out.  I would be  
> wary of actively tracking a production server with STABLE.  If you  
> upgrade to STABLE now and it works, just leave it unless there are  
> security patches.
>
> At least one change is to HEAD/Main which is aka 7-CURRENT.  That  
> would be risky for a production box.
>
> Alternatively you could just try downloading the two files and  
> copying them over your existing ones (after backing them up!) and  
> just try and see if a make buildkernel will compile them.  If the  
> changes don't rely on anything outside of these two files, you'd  
> likely be fine.  Of course, keep a copy of your current working  
> kernel in e.g. /boot/kernel.works.
>
> --Alex
Alex,

Excellent and detailed information. I read the handbook and Complete  
FreeBSD but couldn't grasp the relationship between CURRENT, STABLE,  
and RELEASE and the cvsup tags definitively. This is important when  
buying new hardware running ahead of RELEASE changes (e.g. the  
Broadcom 5704). Last time (a then leading edge server with a U320  
Adaptec controller), I manually updated the driver source just to get  
it to production and made my source out of sync and then feared  
cvsuping further. I think you've given me, in a nutshell, how to do  
this more responsibly. Let me take a shot at it for posterity.

1. Take the machine to STABLE via RELENG_6, if it tests reliably, go  
production and freeze
2. security patch through the .asc file patches until RELEASE 6.2
3. cvsup to RELEASE 6.2 aka RELENG_6_2 (when available and if needed  
hardware changes were indeed incorporated)
4. given no hardware additions, continue to cvsup on RELENG_6_2_0 for  
Security Patches for server life-cycle

I think a light is clicking on.

Thanks VERY much,
Chris