Garance A Drosihn
drosih at rpi.edu
Thu Feb 26 15:23:13 PST 2004
At 12:20 PM -0800 2/26/04, John Polstra wrote:
>On 25-Feb-2004 Garance A Drosihn wrote:
> > At 4:45 PM -0800 2/24/04, John Polstra wrote:
> >> I haven't looked at the patches for a 64-bit time_t, so I'm not
> >> sure what provisions have been made for backward compatibility.
> > None. ...
> >> I assume you (the collective "you") kept compatibility versions
>>> of time(2), stat(2), lstat(2), etc., with 32-bit time_t fields
>>> so that existing executables would continue to work.
>Ugh. Do you folks fully realize the implications of that?
I do. In the UPDATING.64BTT file that I wrote up, probably half
the document is spent trying to make it clear that this change is
>I don't have a SPARC machine, so it's no skin off my nose.
This topic has been discussed a few times in the last few months
(mostly right before 5.2-release). Of freebsd-sparc users who
have replied, a large majority want to jump to 64-bit time_t
now (while sparc64 has a very low user base), instead having to
wait for 6.0-release, and at *that* time go through the change with
a much larger user base. [well, HOPEFULLY a larger one! :-) ]
>But I think you folks might come to regret it if you take this
>shortcut. This platform has already been around for a year, and
>people have developed certain expectations.
It has been available for a year, but it has never been released as
a "ready-for-production" system. For instance, it was only recently
that X11 started working on *any* sparc64 hardware. I think that is
a big factor which favors that we make the change now.
>I've been around here since 1995, and I've seen people talk
>themselves into skipping the backward-compatibility step before.
>They practically always regretted it. I think this is likely to be
I also realize there will be some loose ends due to bugs in programs.
Ie, even *after* recompiling everything, there will be some programs
that will need some changes (maybe a lot of changes) to work right.
One known-example is the DHCP-client in the base system, but it
looks like we can use an existing port to sidestep that particular
So you could still be quite right. I would not feel too bad if
there was an outcry from sparc64 users to put this off until 6.0.
However, we either do it now, or we MUST wait until 6.0. (and
then do the usual handling for a major change, with the standard
provisions for backwards compatibility, etc).
Garance Alistair Drosehn = gad at gilead.netel.rpi.edu
Senior Systems Programmer or gad at freebsd.org
Rensselaer Polytechnic Institute or drosih at rpi.edu
More information about the freebsd-sparc64