Date: Fri, 26 Oct 2001 01:39:20 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Kirk McKusick <mckusick@mckusick.com>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <Pine.BSF.4.21.0110260138360.8805-100000@InterJet.elischer.org> In-Reply-To: <3BD90AFF.4BBEC004@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0110260138360.8805-100000>