Date: Fri, 20 Feb 2004 17:13:11 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: sparc64@freebsd.org Subject: Re: Back to the Future - 64-bit time_t on sparc64 Message-ID: <p0602045abc5c248db8bd@[128.113.24.47]> In-Reply-To: <20040220035635.GA69900@dhcp01.pn.xcllnt.net> References: <40306CE7.6080104@mindspring.com> <20040216193108.GE12181@seekingfire.com> <p0602041ebc56dd660908@[128.113.24.47]> <20040217040616.GL12181@seekingfire.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:56 PM -0800 2/19/04, Marcel Moolenaar wrote:
>On Thu, Feb 19, 2004, Garance A Drosihn wrote:
> >
>> My basic plan is to commit these three files to /usr/src on
> > March 1st. ... Then, at some later date, we'd commit the
> > change to /usr/src/sys/sparc64/include/_types.h which makes
> > the switch, and add an entry in /usr/src/UPDATING ...
> >
>> Does this seem reasonable?
>
>Is there a way we can avoid footshooting?
>
>For example: check if /usr/include/machine/_types.h is equal to
>the one in the source tree and disallow installworld without
>some special define if they're not. The scripts use the define
>to circumvent the anti-footshooting measure. Something along
>those lines...
I would really like to have something like this, but I doubt I
have the time to make it happen. I am not quite sure how it
would be hooked up to the buildworld/installworld process, either.
Maybe Ruslan could help me out there.
In thinking about this, I think the simplest solution would be
some program which is compiled & run at buildworld time, and
which is also run at installworld time. We would want it to
run it as early as possible in the processing of those targets.
I *think* what would work is something like:
In /etc/make.conf, users would define:
SPARCWORLD_TIMET=32bit or SPARCWORLD_TIMET=64bit
If neither is defined, than 32-bit is assumed.
You then have a program in buildworld which simply looks at the
length of time_t that it finds at compile-time, and prints out
a single-line which says '64bit' or '32bit'.
Then, in both buildworld and installworld (and maybe buildkernel
and installkernel), you add logic which says something vaguely
like:
SPARCWORLD_TIMET?=32bit
FOUND_TIMET="`${.OBJDIR}/something/check_program`"
if [ "${SPARCWORLD_TIMET}" != "`check_program`" ] then
echo "You are building a $FOUND_TIMET system, but you seem"
echo "to expect to build a $SPARCWORLD_TIMET system. You"
echo "must either modify /etc/make.conf to add:"
echo " SPARCWORLD_TIMET=$FOUND_TIMET"
echo "or edit /usr/src/sys/sparc64/include/_types.h to"
echo "change the type of __time_t to be <right-value>"
exit 1
fi
If I've done this right, then people will be forced to add
SPARCWORLD_TIMET=64bit to their /etc/make.conf when they
make the switch to 64-bit time_t's. Once they do that, though,
they can be reasonably sure they will never mistakenly build or
install a 32-bit time_t system over an already-64-bit system.
I am certain that there are some details I have overlooked, but I
really don't have the time to think it through right now.
--
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?p0602045abc5c248db8bd>