Date: Sat, 21 Feb 2004 13:18:18 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Garance A Drosihn <drosih@rpi.edu> Cc: sparc64@freebsd.org Subject: Re: Back to the Future - 64-bit time_t on sparc64 Message-ID: <20040221211818.GA71845@dhcp01.pn.xcllnt.net> In-Reply-To: <p0602045fbc5d5375b7d9@[128.113.24.47]> References: <20040219143838.GL68388@seekingfire.com> <p0602044bbc5ac1a48967@[128.113.24.47]> <20040219204008.GB3545@electra.cse.Buffalo.EDU> <p0602044cbc5ad23c6d38@[128.113.24.47]> <20040219205750.GC3545@electra.cse.Buffalo.EDU> <p06020453bc5b2ce4acc3@[128.113.24.47]> <20040220035635.GA69900@dhcp01.pn.xcllnt.net> <p0602045abc5c248db8bd@[128.113.24.47]> <20040221140438.M87450@beagle.fokus.fraunhofer.de> <p0602045fbc5d5375b7d9@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sat, Feb 21, 2004 at 01:59:06PM -0500, Garance A Drosihn wrote:
>
> Why do we want to allow 32-bit builds?
> Because the instructions say:
> First do a 32-bit build. Install it.
> Once you know that that installation is working,
> Change _types.h, do a 64-bit build, and install that.
If we are going to commit this stuff, the requirement to build a
32-bit time_t system first, apply the one-liner to _types.h and
rebuild a 64-bit time_t from the same source tree is not going to
fly anymore. We need to realize that we get people who upgrade
a 32-bit time_t many months old to a 64-bit time_t in a single
pass. This is a risk we need to take. As long as people do not
install anything, a buildworld or buildkernel can fail. The part
that is tricky is that the executables actually run. I'm not too
worried about that.
Note also that we should not make a mountain out of this. I think
upgrading should not be made harder than it really is. All we need
to do is protect the installation targets so that people are
forced to run the scripts when they need to. Remember that we
probably want the footshooting measure for the whole 5-stable
lifetime. Just to be on the safe side.
See attached patch for an implementation of the concept,
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="sparc.diff"
Index: Makefile.inc1
===================================================================
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.405
diff -u -r1.405 Makefile.inc1
--- Makefile.inc1 13 Feb 2004 21:52:08 -0000 1.405
+++ Makefile.inc1 21 Feb 2004 21:15:28 -0000
@@ -342,12 +342,25 @@
buildworld: ${WMAKE_TGTS}
.ORDER: ${WMAKE_TGTS}
+.if ${TARGET_ARCH} == "sparc64"
+SPARC64_ANTI_FOOTSHOOTING=sparc64_installcheck
+OLD_TIME_T!= grep __time_t /usr/include/machine/_types.h | awk '{print $2}'
+NEW_TIME_T!= grep __time_t ${.CURDIR}/sys/sparc64/include/_types.h | awk '{print $2}'
+
+sparc64_installcheck:
+.if ${OLD_TIME_T} != ${NEW_TIME_T}
+ echo use the scripts, Luke!
+ false
+.endif
+
+.endif
+
#
# installcheck
#
# Checks to be sure system is ready for installworld
#
-installcheck:
+installcheck: ${SPARC64_ANTI_FOOTSHOOTING}
.if !defined(NO_SENDMAIL)
@if ! `id -u smmsp > /dev/null`; then \
echo "ERROR: Required smmsp user is missing, see /usr/src/UPDATING."; \
@@ -503,6 +516,9 @@
#
# Install the kernel defined by INSTALLKERNEL
#
+installkernel installkernel.debug: ${SPARC64_ANTI_FOOTSHOOTING}
+reinstallkernel reinstallkernel.debug: ${SPARC64_ANTI_FOOTSHOOTING}
+
installkernel reinstallkernel installkernel.debug reinstallkernel.debug:
.if empty(INSTALLKERNEL)
@echo "ERROR: No kernel \"${KERNCONF}\" to install."
--y0ulUmNC+osPPQO6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040221211818.GA71845>