From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 23:21:06 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 279A716A4CE; Fri, 9 Jan 2004 23:21:06 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 733FC43D48; Fri, 9 Jan 2004 23:20:59 -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 i0A7KwKx032156; Sat, 10 Jan 2004 02:20:59 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040107174346.GA50142@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> <20040107174346.GA50142@dragon.nuxi.com> Date: Sat, 10 Jan 2004 02:20:57 -0500 To: freebsd-sparc64@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: harti@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 07:21:06 -0000 After reading over what Harti had done, and staring at the standard makefiles awhile, I ended up writing one helper- script. With this helper-script, the upgrade to 64-bits went fairly smooth. For my switch, what I did was: cvsup to -current update & install that snapshot (using the standard updating procedures, this is still the 32-bit time_t system) 1) change __time_t to __int64_t 2) rm -Rf /usr/obj/usr/src/* 3) make buildworld && make buildkernel && make installkernel (wait seven hours...) 4) mergemaster -p <- not really needed... 5) reboot into single-user mode. 6) cd /usr/src <- or NFS-mounted equivalent 7) installworld_nk <- magic script 8) mergemaster <- not really needed... 9) Reboot, and come up on complete new 64-bit time_t system. 10) portupgrade -Rr -f ruby portupgrade 11) portupgrade -Rr -f bash python 12) ---> Have To Do Something with CVSUP <--- (in my case, I'll probably rebuild all of ezm3 and cvsup, but I doubt that everyone would want to do that. We probably need to have a pre-built 64-bit cvsup available as pkg or a download) 13) portupgrade other ports... Doing it this way, I hit no snags. Or at least, I haven't noticed any yet. This could be made even easier by collapsing the 'installworld_nk' script into some new 'installworld_nk' target in /usr/src/Makefile. The script tries to be as general a solution as possible -- it is not specific to this 64-bit time_t change. ("nk" is short for "New Kernel") Notes: 1) Since I only change this one single line, there really is no need for doing things like mergemaster. I really like the idea that when switching to 64-bit time_t, that should be the *only* change you're making from a system that you already know is working on your hardware. 4) If one would do 'mergemaster -p', it would probably be best do to it before shutting down, instead of after booting into a 64-bit kernel and 32-bit world. 5) Usually I cheat on this, and I reboot into multi-user mode and then 'shutdown now' to get into single-user mode. That cheat does not work well when making this change. You really have to 'boot -s', pick your shell, and do a 'mount -a'. Probably should start swap too, but I have enough ram that I don't have to care about that part. 5a) For the general case, this is the "shakey-ist" step, because I started up on a /bin/sh which was not built for the new kernel. For this specific change, that did not seem to be a problem. 6) The way I wrote the script, I expect it would work for people who do installs via NFS-mounted filesystems, perhaps mounted at somewhere other than /usr/src. However, I am not setup to test that. I am testing only the standard case of /usr/src and /usr/obj. 7) What the standard 'make installworld' does, is it looks for a list of programs, does a 'which $prog' on them, and copies all of those (from the "old system") into a temp directory, and changes PATH to use that directory. What my script does is take that same list of programs, copies them out of ${.OBJDIR} into a temp directory, changes PATH to add on the new directory, removes one PATH= command from a copy of /usr/src/Makefile, and then runs the standard 'installworld' target. So, using this tactic it should be true that *every* program needed by the installworld process will match the new kernel. I know that doesn't happen for /bin/sh, and I can't prove that it did happen for all other programs, but I did get through the entire installworld without error-ing out. That's why I say this could be collapsed into a new standard target. The script is only doing a slight variation from the standard installworld target. I am not going to *do* that, I'm just saying it could be done. 10) I use portupgrade to update ports, so I figured this was the obvious first-step. After that, I've just been upgrading ports which "I expect" need to be upgraded. After that, I did the dumb test of: irb <- interactive ruby test = Time.now() test += 3600*24*365 and kept repeating the last command. On a 32-bit time_t, the command errors out in 2038. On the new system, it just keeps going up. I hope to do a repeat test of all of this work sometime over the weekend. I also might try to make some more improvements. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu