Back to the Future - 64-bit time_t on sparc64

[Harti Brandt]

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 at fokus.fraunhofer.de, harti at freebsd.org