Date: Fri, 26 Oct 2001 11:42:49 -0500 From: Alfred Perlstein <bright@mu.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Julian Elischer <julian@elischer.org>, Terry Lambert <tlambert2@mindspring.com>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011026114249.E15052@elvis.mu.org> In-Reply-To: <3463.1004114334@critter.freebsd.dk>; from phk@critter.freebsd.dk on Fri, Oct 26, 2001 at 06:38:54PM %2B0200 References: <Pine.BSF.4.21.0110261046280.10928-100000@InterJet.elischer.org> <3463.1004114334@critter.freebsd.dk>
index | next in thread | previous in thread | raw e-mail
* Poul-Henning Kamp <phk@critter.freebsd.dk> [011026 11:39] wrote:
> In message <Pine.BSF.4.21.0110261046280.10928-100000@InterJet.elischer.org>, Ju
> lian Elischer writes:
>
> >considering that we didn't have ANY sub-second resolution for a long time
> >I think that
> >looking for sub microsecond resolution on access times is pointless at
> >this time..
>
> I am looking for it at this time, not _for_ this time, but _for_
> the future.
>
> If state of the art equipment can break the make(1) assumption today,
> what do you think the life expectancy of the designed concept is ?
>
> Certainly not 10+ years.
>
> And have you considered that there may be other and stronger
> requirements than make(1) and that multi-cpu, multi-threaded systems
> may push the envelope ?
>
> Solving the problem means going for a timestamp which can resolve
> any conceiveable CPU frequencies for all relevant future.
I guess I should have more in depth knowledge of these systems by
now, but what's wrong with having the in-core being a full
64/128/whatever bits while the on disk itself doesn't?
At least until Kirk does his new layout, it might be a compromise
to regain out 2037 safety a bit early on.
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011026114249.E15052>