Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Oct 2001 22:42:56 -0800
From:      Peter Wemm <peter@wemm.org>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        arch@FreeBSD.ORG
Subject:   calm, orderly, deliberate time_t transition.. 
Message-ID:  <20011029064257.ACB573808@overcee.netplex.com.au>
In-Reply-To: <p05101006b8027094cbe1@[128.113.24.47]> 

next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosihn wrote:
> At 5:15 PM -0800 10/28/01, David O'Brien wrote:
> >On Sat, Oct 27, 2001, Garance A Drosihn wrote:
> >  > Now use that scale to vote for the following list of suggested
> >>  changes.  Each item in the list is for one specific change,
> >>  and each would be voted on separately.
> >>
> >>     a) For the up-and-coming 64-bit platforms (sparc64, IA-64),
> >>        FreeBSD 5.0-release should have a 64-bit value for time_t.
> >>     b) For the up-and-coming 32-bit platforms (PowerPC),
> >>        FreeBSD 5.0-release should have a 64-bit value for time_t.
> >>     c) For the existing 32-bit platform (i386),
> >>        FreeBSD 5.0-release should have a 64-bit value.
> >>     d) For all 32-bit platforms (PowerPC, i386),
> >>        iff FreeBSD 5.0-release continues to be a 32-bit value,
> >>        then it should be called 'long' instead of 'int'.
> >
> >You left out the Alpha (not surprising as most here seem to ignore
> >it...)
> 
> I think those who run Alpha should vote on Alpha.  I do not run
> Alpha, and do not expect that I personally will get an Alpha
> machine.
> 
> Still, I should have listed it, and I guess I should vote.
> 
> Issue:
>     e) Alpha should have a 64-bit time_t in 5.0-release
> 
> My vote:
>     4.5 - but I am willing to be outvoted by the people who are
>           actually running freebsd/alpha.

Actually, I think the most sensible thing to do here is work from what
we do agree on backwards, and save the most risky things till last so that
we have gained experience.

I think what we do agree on:

1: time_t assumptions in existing code should be fixed.

2: new platforms should start at time_t 64 bit

3: Once we've tested the water on the new platforms, *then* progress
towards activating it on alpha and then x86.

By then we'll have gathered enough *experience* on the new platforms to
know how much pain the alpha and i386 will have, and we can judge whether
its worth it.  Until then, we're speculating.  We have no hard data and
no actual real experience.

If we can agree that the ideal goal is to move toward 64 bit times in a
sane and orderly fashion, and that each major hurdle is to be evaluted as
we come to it, then we can end this damn bikeshed-from-hell and just get on
with it.

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011029064257.ACB573808>