From owner-freebsd-sparc64@FreeBSD.ORG Mon Oct 20 01:01:12 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4EDC16A4B3; Mon, 20 Oct 2003 01:01:12 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B94F43FCB; Mon, 20 Oct 2003 01:01:11 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9K812D03347; Mon, 20 Oct 2003 10:01:03 +0200 (MEST) Date: Mon, 20 Oct 2003 10:01:02 +0200 (CEST) From: Harti Brandt To: Garance A Drosihn In-Reply-To: Message-ID: <20031020095526.N47918@beagle.fokus.fraunhofer.de> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kris Kennaway cc: standards@freebsd.org cc: sparc64@freebsd.org cc: Bruce Evans cc: Marcel Moolenaar Subject: Re: time_t on sparc64 (it seems to work) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2003 08:01:12 -0000 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