Date: Sat, 21 Feb 2004 17:23:55 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: sparc64@freebsd.org Subject: Re: Back to the Future - 64-bit time_t on sparc64 Message-ID: <p06020462bc5d82e1d51c@[128.113.24.47]> In-Reply-To: <20040221211818.GA71845@dhcp01.pn.xcllnt.net> References: <20040219143838.GL68388@seekingfire.com> <p0602044bbc5ac1a48967@[128.113.24.47]> <20040219204008.GB3545@electra.cse.Buffalo.EDU> <p0602044cbc5ad23c6d38@[128.113.24.47]> <20040219205750.GC3545@electra.cse.Buffalo.EDU> <p06020453bc5b2ce4acc3@[128.113.24.47]> <20040220035635.GA69900@dhcp01.pn.xcllnt.net> <p0602045abc5c248db8bd@[128.113.24.47]> <20040221140438.M87450@beagle.fokus.fraunhofer.de> <p0602045fbc5d5375b7d9@[128.113.24.47]> <20040221211818.GA71845@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020462bc5d82e1d51c>