Date: Fri, 26 Oct 2001 10:07:15 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: Terry Lambert <tlambert2@mindspring.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110261707.f9QH7F437553@apollo.backplane.com> References: <Pine.BSF.4.21.0110261046280.10928-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
For UFS we obviously re-coopt the nanosecond field. Thanks Kirk!
I suggest simply changing di_atimensec (and friends) to di_atimemsb,
to hold the msb 32 bits, allowing us to maintain backwards compatibility.
The question before us is whether we should eat some of those 64 bits and
attempt to store sub-second timestamps.
This is a bad idea. There's no point, because processors are only
getting faster. Even nanosecond resolution isn't enough and we have
other issues simply due to new computing methodologies such as parallel
and distributed processing. 'make's issues aren't enough to justify
complexifying atime/ctime/mtime.
The larger problem that we need to solve are the ridiculous calendar
limitations. We have to solve the problem *permanently* this time,
we have to solve them obviously, with as little additional complexity
as possible. We have to have a solution that is *uniform* across the
system, and a full 64 bit 1-second resolution field will do that.
We should not be screwing around with other clutter.
I am not against adding additional fields to struct stat to support
sub-second resolution for mtime, but I am against attempting to
integrate such fields into st_atime/st_mtime/st_ctime directly.
Unfortunately we only have two spare 64 bit fields in struct nstat.
They aren't enough to fix the time fields and maintain backwards
compatibility. Unless I'm missing something here, we are going to have
to roll new syscalls for *stat() and *utimes() (any others?)
-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?200110261707.f9QH7F437553>