Date: Mon, 20 Oct 2003 10:01:02 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Garance A Drosihn <drosih@rpi.edu> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: time_t on sparc64 (it seems to work) Message-ID: <20031020095526.N47918@beagle.fokus.fraunhofer.de> In-Reply-To: <p0600200ebbb5eb2c472a@[128.113.24.47]> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015075111.GA52914@rot13.obsecurity.org> <20031015190951.GA638@ns1.xcllnt.net> <20031016123335.L57857@beagle.fokus.fraunhofer.de> <p0600200ebbb5eb2c472a@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031020095526.N47918>