From owner-freebsd-arch@FreeBSD.ORG Sun Feb 22 18:58:48 2004 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 151FA16A4CE; Sun, 22 Feb 2004 18:58:48 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBAD043D1D; Sun, 22 Feb 2004 18:58:47 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i1N2wjnI014632; Sun, 22 Feb 2004 21:58:46 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sun, 22 Feb 2004 21:58:45 -0500 To: current@FreeBSD.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) X-Mailman-Approved-At: Mon, 23 Feb 2004 04:59:42 -0800 cc: Bruce Evans Subject: HEADSUP: Commits Planned for 64-bit time_t on sparc64 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: Mon, 23 Feb 2004 02:58:48 -0000 [this is being BCC'ed to -arch and -hackers just to make sure that everyone is aware of this before changes are committed, but I expect all of the discussion to happen on -current] Sparc64 users (including me) have said that we'd like the sparc64 port to be running with a 64-bit time_t before we make a "stable" branch for the 5.x-series. I have been working on a procedure that can be used to safely perform this very incompatible change. I think I finally have that pretty much ready-to-go. I will therefore make the bold claim that I plan to take the files you can find at: http://people.freebsd.org/~gad/time-64/UPDATING.64BTT http://people.freebsd.org/~gad/time-64/installworld_oldk http://people.freebsd.org/~gad/time-64/installworld_newk and I plan to commit them to /usr/src, on Wed March 3rd. This does not actually change anything, but it tells adventurous sparc64 users that we're officially on the way to making this change, so they can try upgrades to 64-bTT (64-bit time_t). These files are only going to be in the base system long enough to help sparc64 users through the transition. I am very interested in any "show-stopper" problems in what I have written. My hope is that these files will disappear shortly after 5.3-release, though, so I don't want to spend much time polishing the scripts up when it comes to style issues. I'm still interested in hearing about them, but I may not be in a rush to do anything about style issues. Assuming that no one runs into a show-stopper problem, I plan to commit the change to /usr/src/sys/sparc64/include/_types.h that switches to 64-bTT for sparc. /usr/src/UPDATING will also need to have an entry added, but that entry will just point to the /usr/src/UPDATING.64bTT file. I plan to commit this (or have Warner commit the change to UPDATING?) on Wednesday March 10th. All of these changes will cause zero changes for people who are running on other hardware platforms. Only sparc64 users have to lay awake in terror of what this change might do to them. I should note that it *has* been working fine for me... :-) Also, about a dozen other sparc64 users have used these files to make a successful transition, with very few problems reported. As for me, I expect that my real-work job is going to get much busier by March 15th. If this 64-bTT change is not committed at that point, then some other developer will have to lead the charge for making the change. And, personally, I think we are already awfully close to the time for 5.3-release, and we can not afford to get much closer to it before making this change. So if we can not make this change by March 15th (at the latest), then I think we will have to put it off until 6.0. In fact, if I had a fix for the dhclient issue I would prefer to move both of the planned commits up by a week. I know this could be improved upon if I had more time to work on it, but this is basically the best I could do with the time I had. If my main job had something to do with FreeBSD, then I would have some way to justify spending more time working on issues like this... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu