Gearing up for 64-bit time_t on sparc64
Garance A Drosihn
drosih at rpi.edu
Fri Jan 9 23:21:06 PST 2004
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 at gilead.netel.rpi.edu
Senior Systems Programmer or gad at freebsd.org
Rensselaer Polytechnic Institute or drosih at rpi.edu
More information about the freebsd-sparc64
mailing list