Date: Fri, 26 Oct 2001 00:04:31 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <3BD90AFF.4BBEC004@mindspring.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk McKusick wrote: > > I vote for option (3), 64-bit time_t for all 64 bit architectures. > I would go along with option (4) provided that the change-over came > with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > The change from 4.X to 5.0 will have enough other things going on > that I do not think that adding the time_t change would cause a > lot more pain provided that old dump tapes and log files could > be read. Since we have you here... The 32 bit reserve time in the on disk time, which was taken over for the "nanotime", was reserved for a 64 bit time_t in the UFS on disk structures, right? It seems to me that if higher resolution is needed on mtime for things like "make", that it should be limited to mtime _only_, and that that could take a different, single reserve field, instead of taking up 32 bits for every time value. So again: the 64 bit reserved area adjacent to the times was intended for a 64 bit second counter, right? This has been a long standing annoyance to me (my systems have run this way since late 1995) that this apparently reserved area for handling exactly this problem was coopted to make really fast systems not rebuild object files. -- Terry 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?3BD90AFF.4BBEC004>