From owner-freebsd-arch Tue Oct 30 11:57:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 7503837B403 for ; Tue, 30 Oct 2001 11:57:42 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9UJvUI76150; Tue, 30 Oct 2001 14:57:30 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200110301834.f9UIYeR94440@apollo.backplane.com> References: <20011030210857.R1525-100000@delplex.bde.org> <200110301834.f9UIYeR94440@apollo.backplane.com> Date: Tue, 30 Oct 2001 14:57:28 -0500 To: Matthew Dillon , Bruce Evans From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Cc: Julian Elischer , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 10:34 AM -0800 10/30/01, Matthew Dillon wrote: > 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). My understanding is that we have two debates going. One for time_t being 64-bit, and a related one for what we should do about time_t values which are stored on disk as part of UFS. It is probably way too disruptive to change the size of those fields, so those fields probably have to stay 32-bit. So then the question is "can we make those UFS fields be unsigned, so they'll last past 2038?". I don't think anyone is pushing for time_t itself to be unsigned. (someone correct me if I'm wrong... :-) > 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. I think the Alpha crowd is saying that they don't want that platform to change unless IA32 also changes, at least not for 5.0-release. I do not know if it makes sense to move to 64-bit on new platforms, and then decide about rolling the system calls on older platforms at some later date... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message