Date: Sat, 21 Feb 2004 14:07:39 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Garance A Drosihn <drosih@rpi.edu> Cc: ru@freebsd.org Subject: Re: Back to the Future - 64-bit time_t on sparc64 Message-ID: <20040221140438.M87450@beagle.fokus.fraunhofer.de> In-Reply-To: <p0602045abc5c248db8bd@[128.113.24.47]> References: <40306CE7.6080104@mindspring.com> <20040216193108.GE12181@seekingfire.com> <20040217040616.GL12181@seekingfire.com> <p0602044bbc5ac1a48967@[128.113.24.47]> <p0602044cbc5ad23c6d38@[128.113.24.47]> <p06020453bc5b2ce4acc3@[128.113.24.47]> <p0602045abc5c248db8bd@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Feb 2004, Garance A Drosihn wrote:
GAD>At 7:56 PM -0800 2/19/04, Marcel Moolenaar wrote:
GAD>>On Thu, Feb 19, 2004, Garance A Drosihn wrote:
GAD>> >
GAD>>> My basic plan is to commit these three files to /usr/src on
GAD>> > March 1st. ... Then, at some later date, we'd commit the
GAD>> > change to /usr/src/sys/sparc64/include/_types.h which makes
GAD>> > the switch, and add an entry in /usr/src/UPDATING ...
GAD>> >
GAD>>> Does this seem reasonable?
GAD>>
GAD>>Is there a way we can avoid footshooting?
GAD>>
GAD>>For example: check if /usr/include/machine/_types.h is equal to
GAD>>the one in the source tree and disallow installworld without
GAD>>some special define if they're not. The scripts use the define
GAD>>to circumvent the anti-footshooting measure. Something along
GAD>>those lines...
GAD>
GAD>I would really like to have something like this, but I doubt I
GAD>have the time to make it happen. I am not quite sure how it
GAD>would be hooked up to the buildworld/installworld process, either.
GAD>Maybe Ruslan could help me out there.
GAD>
GAD>In thinking about this, I think the simplest solution would be
GAD>some program which is compiled & run at buildworld time, and
GAD>which is also run at installworld time. We would want it to
GAD>run it as early as possible in the processing of those targets.
GAD>
GAD>I *think* what would work is something like:
GAD>In /etc/make.conf, users would define:
GAD>
GAD>SPARCWORLD_TIMET=32bit or SPARCWORLD_TIMET=64bit
GAD>
GAD>If neither is defined, than 32-bit is assumed.
That would look like an option to build either way and
I think we shouldn't have such an option that allows 32bit time_t's. This
will require to ship to sets of packages and will give as a lot of
bug reports because of mismatched packages and kernels.
GAD>You then have a program in buildworld which simply looks at the
GAD>length of time_t that it finds at compile-time, and prints out
GAD>a single-line which says '64bit' or '32bit'.
GAD>
GAD>Then, in both buildworld and installworld (and maybe buildkernel
GAD>and installkernel), you add logic which says something vaguely
GAD>like:
GAD>
GAD> SPARCWORLD_TIMET?=32bit
GAD> FOUND_TIMET="`${.OBJDIR}/something/check_program`"
GAD> if [ "${SPARCWORLD_TIMET}" != "`check_program`" ] then
GAD> echo "You are building a $FOUND_TIMET system, but you seem"
GAD> echo "to expect to build a $SPARCWORLD_TIMET system. You"
GAD> echo "must either modify /etc/make.conf to add:"
GAD> echo " SPARCWORLD_TIMET=$FOUND_TIMET"
GAD> echo "or edit /usr/src/sys/sparc64/include/_types.h to"
GAD> echo "change the type of __time_t to be <right-value>"
GAD> exit 1
GAD> fi
GAD>
GAD>If I've done this right, then people will be forced to add
GAD>SPARCWORLD_TIMET=64bit to their /etc/make.conf when they
GAD>make the switch to 64-bit time_t's. Once they do that, though,
GAD>they can be reasonably sure they will never mistakenly build or
GAD>install a 32-bit time_t system over an already-64-bit system.
GAD>
GAD>I am certain that there are some details I have overlooked, but I
GAD>really don't have the time to think it through right now.
GAD>
GAD>
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040221140438.M87450>