Date: Tue, 30 Oct 2001 10:34:40 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bruce Evans <bde@zeta.org.au> Cc: Julian Elischer <julian@elischer.org>, Nate Williams <nate@yogotech.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, <arch@FreeBSD.ORG> Subject: Re: 64 bit times revisited.. Message-ID: <200110301834.f9UIYeR94440@apollo.backplane.com> References: <20011030210857.R1525-100000@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Mon, 29 Oct 2001, Julian Elischer wrote:
:
:> and you really want us to believe that data file came form 1910?
:
:I simply refuted a false claim that timestamps can't be before 1970.
:
:> On Tue, 30 Oct 2001, Bruce Evans wrote:
:>
:> > On Mon, 29 Oct 2001, Julian Elischer wrote:
:> >
:> > > be used for multiplying the seconds scale by 4. (in UFS timestamps..
:> > > you would never write a non-normalised time to disk)
:> > > also timestamps can't be before 1970 so making it unsigned
:> > > allows us to go to 2100+ and mutiplying it by for takes us to about 2600..
:> >
:> > Script started on Tue Oct 30 06:55:55 2001
:> > ttyp1:bde@gamplex:/tmp> touch -t 191001011230 foo
:> > ttyp1:bde@gamplex:/tmp> ls -l foo
:> > -rw-r--r-- 1 bde wheel 0 Jan 1 1910 foo
:> > ttyp1:bde@gamplex:/tmp> exit
:> >
:> > Script done on Tue Oct 30 06:56:10 2001
:
:This mailing list is approaching the quality of the average newsgroup,
:complete with top posting by newbies.
:
:Bruce
We can't make time_t unsigned anyway. A huge amount of code
(hundreds of instances) do delta comparisons and simply assume
that time_t is signed. With it unsigned many of those comparisons
would blow up (return true when they should return false).
I'm about ready to give up trying to convince people that it's worth
moving IA32 to 64 bit timestamps. The bigger issue, however, is
what to do about 64 bit platforms. I keep finding system calls
that need to be rolled. The list is now getting pretty big. I am
up to 22 system calls.
This means that if we are NOT going to change IA32 but we ARE going
to change 64 bit architectures, then we should do it *without*
rolling system calls at all which would mean having to eat any
binary incompatibilities from older code. It might conceivably be
worth rolling the syscalls if we were to change IA32, but if we aren't
it just isn't worth it to roll the syscalls just to support
pre-time-change 64 bit platforms.
-Matt
Matthew Dillon
<dillon@backplane.com>
7 MCOMPAT2 BSD { int wait4(int pid, int *status, int options, \
83 MCOMPAT2 BSD { int setitimer(u_int which, struct o2itimerval *itv, \
86 MCOMPAT2 BSD { int getitimer(u_int which, struct o2itimerval *itv); }
93 MCOMPAT2 BSD { int select(int nd, fd_set *in, fd_set *ou, \
116 MCOMPAT2 BSD { int gettimeofday(struct o2timeval *tp, \
117 MCOMPAT2 BSD { int getrusage(int who, struct o2rusage *rusage); }
122 MCOMPAT2 BSD { int settimeofday(struct o2timeval *tv, \
138 COMPAT2 BSD { int utimes(char *path, struct o2timeval *tptr); }
140 MCOMPAT2 BSD { int adjtime(struct o2timeval *delta, \
188 COMPAT2 POSIX { int stat(char *path, struct o2stat *ub); }
189 MCOMPAT2 POSIX { int fstat(int fd, struct o2stat *sb); }
190 COMPAT2 POSIX { int lstat(char *path, struct o2stat *ub); }
206 COMPAT2 BSD { int futimes(int fd, struct o2timeval *tptr); }
232 MCOMPAT2 POSIX { int clock_gettime(clockid_t clock_id, \
233 MCOMPAT2 POSIX { int clock_settime(clockid_t clock_id, \
234 MCOMPAT2 POSIX { int clock_getres(clockid_t clock_id, \
240 MCOMPAT2 POSIX { int nanosleep(const struct o2timespec *rqtp, \
276 COMPAT2 BSD { int lutimes(char *path, struct o2timeval *tptr); }
299 COMPAT2 BSD { int fhstat(const struct fhandle *u_fhp, struct o2stat *sb); }
315 COMPAT2 BSD { int aio_suspend(struct aiocb * const * aiocbp, int nent, const struct o2timespec *timeout); }
334 MCOMPAT2 POSIX { int sched_rr_get_interval (pid_t pid, struct o2timespec *interval); }
363 MCOMPAT2 BSD { int kevent(int fd, \
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?200110301834.f9UIYeR94440>