Date: Mon, 29 Oct 2001 06:49:37 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011029064937.C75481@gsmx07.alcatel.com.au> In-Reply-To: <200110260020.f9Q0KQR63759@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Oct 25, 2001 at 08:20:26PM -0400 References: <20011025233602.587C63808@overcee.netplex.com.au> <200110260020.f9Q0KQR63759@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 25, 2001 at 08:20:26PM -0400, Garrett Wollman wrote: >V) Do what the Large File Summit did for off_t: define 32- and 64-bit >versions of every interface that uses a time_t, and let a preprocessor >macro switch between them. How many syscalls would this impact? My guess is that it would be a significant number. Also, this approach can easily lead to exponential growth in the number of syscalls: Consider a hypothetical system that has two off_t sizes and two time_t sizes - it will need 4 stat() syscalls (and maybe others). It's also relatively difficult to recover old syscalls. (A number of wrapper functions around a single syscall() would be more manageable). > On new platforms (regardless of native word size), use the 64-bit >versions. I agree about using a 64-bit time_t for new 64-bit (or larger) architectures. I'm less certain about using 64-bit time_t on any new 32-bit architectures - supporting double-width operation is usually fairly expensive. > Meanwhile, start deploying a new inode format with 64-bit times. This is a different bikeshed - we need to extend the inode timestamps at both ends - we need more resolution as well as more range. (The 1-second granularity has been a problem for a few years already). It's unclear how to easily achieve this (since C doesn't have native support for fixed-point binary types and bitfields are only supported for int (and shorter) types). Peter 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?20011029064937.C75481>