Date: Sat, 10 Jan 2004 02:20:57 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: freebsd-sparc64@freebsd.org Cc: harti@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 Message-ID: <p06020452bc2549a6ba9e@[128.113.24.47]> In-Reply-To: <20040107174346.GA50142@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <p0602040fbc0cf0dddf9e@[128.113.24.47]> <p06020426bc1fe1f269d8@[128.113.24.47]> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> <p0602042abc2138069732@[128.113.24.47]> <20040107174346.GA50142@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020452bc2549a6ba9e>