Date: Thu, 25 Oct 2001 17:28:11 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <Pine.BSF.4.21.0110251708240.99888-100000@beppo> In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> It was pointed out that *all* the linux 64 bit arches have 64 bit time_t, > so obviously it isn't too hard a problem to solve. No, that's not a fair comparison as linux pays for such ease by making very little committment to true machine/arch independent code. > .. > notable exceptions where times are explicitly sized: > ufs inode format (has ufs_time_t == 32 bits explicitly) > nfs (uses 32 bit timestamps in v3, and 64 bit on v4 (I believe)). v4 isn't real yet, and we don't do well with v3 yet, so I wouldn't worry a lot about this yet. Can we assume that up until the year 2038 or so we can always stuff a value in a current time_t back into a 32 bit time value? Is this true for all values which we wish to really consider as values that are external representations that are portable? If so, then we should just stick to 32 bits for this. > I am starting to wonder now if we're doing ourselves a long-term disservice > by locking time_t into 32 bit. People may say "but we can resolve it closer > to the time", but they also said that about 32 bit file sizes. Look at the > trouble that Linux is still having with applications and libraries due to > the transition from off_t being 32 bits to 64 bits, and recall how little > pain we had because 4.4BSD did it right from the start. Again, I'm not sure this is a fair comparison. There's a real need to exceed a 4GB space with file offsets. But unless time starts running faster than the current one second per second I guess I don't see what the problem is between now and 2038. Oh, all right, 2028- give some slop. Now- if you're talking about time values where we carry current time stamps around to be measured to the nanosecond- yes, *that's* going to be required. I raised this with Bosko recently about the time stamp stuff he's doing- it's getting somewhat pointless to not have at minimum 64 bit counters for that kind of resolution. >.. > unix will be around in another 20 years, but I'd sure like to think that > we dont help contribute to our demise by not having a long term solution > to the time_t wraparound problem. That's a long time away. Frankly, anything that is a exposed to multiple architectures should be restricted to the *minimum* usable size for the next 20 years- the costs of changeover are high now, and make the platforms with the smaller natural word size pay high penalties for very little gain. So, I would suggest going the other way- break alpha so that time_t is 32 bits on alpha. There *is* no installed base for alpha (effectively). This is stated more as an extreme position the other way, just to see what it tastes like. The pros of this is that then we have a clear mandate to make all of the platforms the same standard size to promote interoperability. Otherwise I think #3 is the best. I don't really think #4 is the right thing to do because it will probably really break i386 and make things bloated, Kirk's opinions not withstanding. And, btw, I think Garrett's idea is neat, but way overengineered. FWIW. Oh- yeah- this is too big of an issue to really turn into a bikeshed discussion- this is more like "shall we build a 5000 megawatt nuclear power plant next month?".. Thanks for bringing it up. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0110251708240.99888-100000>