From owner-freebsd-arch Fri Oct 26 0:12:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 6BA0537B406 for ; Fri, 26 Oct 2001 00:12:16 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA08948; Fri, 26 Oct 2001 01:39:22 -0700 (PDT) Date: Fri, 26 Oct 2001 01:39:20 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Kirk McKusick , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-Reply-To: <3BD90AFF.4BBEC004@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 26 Oct 2001, Terry Lambert wrote: > 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? > you can split the field and have enough of both.... > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message