Back to the Future - 64-bit time_t on sparc64

[Garance A Drosihn]

At 1:18 PM -0800 2/21/04, Marcel Moolenaar wrote:
>On Sat, Feb 21, 2004, Garance A Drosihn wrote:
>  >
>>  Why do we want to allow 32-bit builds?
>>  Because the instructions say:
>>         First do a 32-bit build.  Install it.
>>         Once you know that that installation is working,
>>         Change _types.h, do a 64-bit build, and install that.
>
>If we are going to commit this stuff, the requirement to build a
>32-bit time_t system first, apply the one-liner to _types.h and
>rebuild a 64-bit time_t from the same source tree is not going to
>fly anymore. We need to realize that we get people who upgrade
>a 32-bit time_t many months old to a 64-bit time_t in a single
>pass.

I do realize that.  I think I think these people will run into
extra trouble if they are not willing to do two buildworlds once
they do have the time to make this jump.

>This is a risk we need to take.

I am perhaps a little paranoid on this issue, but this *is* a
disruptive change.  I think people will just be worse off if we
imply that they do not have to take fact that into account.

If people don't want to do two buildworlds, than that is a risk that
*they* are taking.  It is not a risk that I am comfortable telling
them to take, because I will have no help for them if things go
wrong.  The amount of time that they will lose if they get into
serious trouble is going to be much greater than the time it would
take to do the extra buildworld.

If we want a simple, trusty upgrade path such that everyone can
treat this like any other upgrade, then we're going to have to go
throught the full process of providing backwards compatibility,
and we will have to wait until 6.0-release to do it.

>See attached patch for an implementation of the concept,

Something along these lines would be nice to have.  It would be
nicer to have something that catches the mistake at buildworld
time, but this is certainly better than doing nothing.

Note that I do not know enough about the installworld/installkernel
targets to say if this is safe enough to use, but from what little
I do know it seems okay.  As I have implied earlier, I don't really
have the time to debug this idea, but I think it's a good idea to do.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu