From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 22:24:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9CB216A4CE; Fri, 14 Nov 2003 22:24:30 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF38A43FA3; Fri, 14 Nov 2003 22:24:29 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.10/8.12.9) with ESMTP id hAF6OTYR019044; Sat, 15 Nov 2003 01:24:29 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sat, 15 Nov 2003 01:24:28 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 06:24:30 -0000 Recently on the freebsd-sparc64 list, it was mentioned that it would be nice to upgrade time_t on that port to be 64-bit. It is pretty obvious (to me at least) that we could bite the bullet and do it (disruptively) right now. If we don't, then (IMO) we pretty much have to wait until the 6.x-branch. On the plus side for doing it RightNow: The amd64 and ia64 ports already have a 64-bit time_t, and it would be nice if the sparc64 port did too. It will be easier to do it now (when sparc64 has very few users), then it will be a few years from now (by the time 6.0-release is released). Harti Brandt did do a buildworld/installworld of a 64-bit time_t on sparc64, and it seemed to work pretty well once he made it through the install. On the minus side: The sparc64 port is big-endian, while the ia64 and amd64 ports are little-endian, so incorrect code is more likely to cause serious problems on sparc64. (maybe that's a good thing...). There is already plenty to do for 5.2-release. The code freeze is about 48 hours away. When this came up on the sparc64 list, I believe there were four people who offered to do help with some of the work that would be caused by making this change. Me, Marcel, Matt@grogged.dyndns, and Harti. No one jumped up and said they were explicitly against the idea. On the other hand, none of us who do want the change really have a lot of time to devote to whatever problems come up. Given the imminent code freeze, I am not comfortable with commiting the actual change for 64-bit time_t on sparc64 given only four people who seem actively interested. On the other hand, I haven't the slightest idea how many people are actively running sparc64... Maybe four is a significant part of the active userbase! So, I thought I'd explicitly say that I don't think we should make the change this late in the game.. But I *would* be happy if other developers wanted to shout me down and go ahead with the it... :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu