Date: Fri, 26 Oct 2001 14:48:33 -0700 From: Peter Wemm <peter@wemm.org> To: David Greenman <dg@root.com> Cc: Julian Elischer <julian@elischer.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, tlambert2@mindspring.com, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026214833.5C3E4380A@overcee.netplex.com.au> In-Reply-To: <20011026100039.C58218@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > >but here;s a better idea anyhow.. > > > >take the TOP 2 bits.. they can never be used now anyhow.... > >that gives us nanosecond resolution, which is all we can report now > >anyway, and multiplies the seconds range by 4. Assuming that we do not > >allow access times < 1970 on disk (there were no such files then, > >then we are ok up to the year 2600, by which time we hope there are no > >embededded systems from the next 5 years still running..... > > Any solution that tries to bandaid the problem by using a few bits from > here or there is unacceptable to me. I have mixed feelings about changing > to phk's 1/1^64 fractional timestamp idea, but I do think that we should > make time_t 64 bits on all architectures, including x86, starting with v5 > of FreeBSD. > > -DG I certainly agree with the dislike of using bandaids, bits or hacks. Kirk is refreshing FFS, which sounds like it solves the problem nicely. FFS should not be an issue here. The other on-disk formats need a type-safe definition, and thats all there is to it. We can incrementally introduce 64 bit time support there at our leisure. pwd.db, for example, is easy. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20011026214833.5C3E4380A>