time_t on sparc64 (it seems to work)

[Harti Brandt]

On Fri, 17 Oct 2003, Garance A Drosihn wrote:

GAD>At 12:47 PM +0200 10/16/03, Harti Brandt wrote:
GAD>>
GAD>>Well, I tried to get a first impression on how hard this
GAD>>change would be.  I have a ultra-10 to play with.
GAD>>
GAD>>The only thing I did (after a couple of greps in sys/sparc64)
GAD>>was to change __time_t to __int64_t. I then recompiled
GAD>>everything and installed the new kernel. Just for fun I booted
GAD>>the kernel and - hey - it works.  ...
GAD>>rebooted the new kernel into single user, mounted my NFS file
GAD>>systems (my src and obj are on a server) by hand and tried the
GAD>>make install again. This time it stopped in include, probably
GAD>>because it was now using the old make which couldn't correctly
GAD>>resolve the file times anymore. I installed the new make
GAD>>handish and tried the installworld again. This time it stopped
GAD>>in sendmail, because the old find doesn't work as expected.
GAD>>Installing the new find did the trick. After a mergemaster and
GAD>>a reboot everything seems to be just fine.
GAD>
GAD>>So given that things are quite simple I would argue to do the
GAD>>move now, before the sparc port will really be used as -stable
GAD>>in production systems.
GAD>
GAD>I would say that your own description falls a little short of
GAD>being "quite simple"...

The only real problem I can see is zic. My intention for a solution
was to use 'make -k installworld', and when it starts to hang running
zip, you kill zip. After the installworld finishes you do another
installworld (now without -k and you're done).

GAD>>Of course you need to recompile all ports (unless you know
GAD>>which port won't used stat() or gettimeofday().
GAD>
GAD>Which is even more work that every-sparc64-user would have to
GAD>do.  It also means that there is a lot that you have not really
GAD>tested with the above.  It also means that any pkg-building
GAD>will have provide packages for both 64-bit and 32-bit time_t
GAD>systems, unless you can somehow get everyone to rebuild their
GAD>systems on the same day.

Yes. But. The problems when we move to 64-bit in 6.0 are a good deal
larger, because we're going to have a user base that will have critical
data in files that have 32-bit time_t's.

GAD>>With a little help from the build infrastructure people it
GAD>>may be possible to ensure that the above will work more
GAD>>automatically.
GAD>
GAD>But that is also "more work" for some developers would have to
GAD>do, and they'd have to do it "right now".

Yes.

GAD>
GAD>>So when will we do it?
GAD>
GAD>I definitely do like the idea of getting to 64-bit time_t on
GAD>sparc64 before 5.2-release, but there is no question that it
GAD>adds to the work necessary before "5.x" becomes "5.x-stable".
GAD>
GAD>If we are going to do it, we should talk as if we are going
GAD>to do it "Right Now", or we should admit that it must wait
GAD>until 6.0-current.  I am willing to go through the same steps
GAD>that you went through to get my one (1) sparc64 system to be
GAD>running with 64-bit timestamps.  I'm willing to recompile all
GAD>the ports on mine.  However, I don't really use my sparc64
GAD>system for all that much, and I can afford to erase the disk
GAD>and start over if this really botches things up.  And even
GAD>if everything that I do works fine, that won't be much of a
GAD>test.  There is a lot of stuff that I do NOT do which someone
GAD>would be doing if they used a sparc64 system as their primary
GAD>desktop machine.
GAD>
GAD>So I am willing to try to do a 64-bit time_t on my one system,
GAD>but only if there is a list of others who are going to do the
GAD>same thing.  We're only going to get from "here" to "there" if
GAD>we start working on it, and we must see multiple developers
GAD>stepping up Right Now who are willing to do that work (even if
GAD>it's just testing-work, it has to be done).
GAD>
GAD>Otherwise, let's concentrate on getting to 5.x-stable, and put
GAD>off all talk of 64-bit time_t's until we create 6.0-current.

Count me as a YES vote for doing the move right now.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org