Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Jan 2004 09:43:46 -0800
From:      "David O'Brien" <obrien@freebsd.org>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        freebsd-sparc64@freebsd.org
Subject:   Re: Gearing up for 64-bit time_t on sparc64
Message-ID:  <20040107174346.GA50142@dragon.nuxi.com>
In-Reply-To: <p0602042abc2138069732@[128.113.24.47]>
References:  <200312212239.38557.craig@xfoil.gank.org> <p0602040fbc0cf0dddf9e@[128.113.24.47]> <p06020426bc1fe1f269d8@[128.113.24.47]> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> <p0602042abc2138069732@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 07, 2004 at 12:08:13AM -0500, Garance A Drosihn wrote:
> How flexible should we be?  My first thought is to tell people:
> 
>    1) upgrade to RELENG_5_2
>    2) *after* you know that upgrade worked, then run a patch
>       file (which will already be in /usr/src?), which will
>       modify the appropriate files needed for this change.
>    3) rebuild after making just that one change.  No cvsup.

I think it has to all be doable given a CVS archive, no external patches.
If need be:

    cvs up -Pd -r RELENG_5_2
    make buildworld
    make kernel
    reboot
    make installworld

    cvs up -Pd -D '<some date>'
    make ...    ---\
    reboot          | what ever is the debugged order to do things...
    make ...    ---/

    cvs up -PdA
    make buildworld
    make kernel
    reboot
    make installworld

> Or we could do a more flexible version, combining a -Define in
> CFLAGS (set in /etc/make.conf), along with some extra magic
> when installing the include files during 'make installworld'.
> Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64.

I think we should only do this if we can't achieve this as above.
 
> The remaining steps would be the same, but users could flip
> the switch at whatever time they wanted, instead of being
> forced to upgrade to RELENG_5_2.

I think that will be a nightmare of too much potential for people doing
it wrong.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040107174346.GA50142>