From owner-freebsd-standards@FreeBSD.ORG Fri Oct 17 12:27:59 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CE5516A4B3; Fri, 17 Oct 2003 12:27:59 -0700 (PDT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3834F43FAF; Fri, 17 Oct 2003 12:27:58 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.10/8.12.9) with ESMTP id h9HJRu8j016332; Fri, 17 Oct 2003 15:27:56 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031016123335.L57857@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031014225053.GA59096@dhcp01.pn.xcllnt.net> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015074437.GA60338@dhcp01.pn.xcllnt.net> <20031015075111.GA52914@rot13.obsecurity.org> <20031015190951.GA638@ns1.xcllnt.net> <20031016123335.L57857@beagle.fokus.fraunhofer.de> Date: Fri, 17 Oct 2003 15:27:54 -0400 To: harti@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: Kris Kennaway cc: standards@freebsd.org cc: sparc64@freebsd.org cc: Marcel Moolenaar Subject: Re: time_t on sparc64 (it seems to work) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2003 19:27:59 -0000 At 12:47 PM +0200 10/16/03, Harti Brandt wrote: > >Well, I tried to get a first impression on how hard this >change would be. I have a ultra-10 to play with. > >The only thing I did (after a couple of greps in sys/sparc64) >was to change __time_t to __int64_t. I then recompiled >everything and installed the new kernel. Just for fun I booted >the kernel and - hey - it works. ... >rebooted the new kernel into single user, mounted my NFS file >systems (my src and obj are on a server) by hand and tried the >make install again. This time it stopped in include, probably >because it was now using the old make which couldn't correctly >resolve the file times anymore. I installed the new make >handish and tried the installworld again. This time it stopped >in sendmail, because the old find doesn't work as expected. >Installing the new find did the trick. After a mergemaster and >a reboot everything seems to be just fine. >So given that things are quite simple I would argue to do the >move now, before the sparc port will really be used as -stable >in production systems. I would say that your own description falls a little short of being "quite simple"... >Of course you need to recompile all ports (unless you know >which port won't used stat() or gettimeofday(). Which is even more work that every-sparc64-user would have to do. It also means that there is a lot that you have not really tested with the above. It also means that any pkg-building will have provide packages for both 64-bit and 32-bit time_t systems, unless you can somehow get everyone to rebuild their systems on the same day. >With a little help from the build infrastructure people it >may be possible to ensure that the above will work more >automatically. But that is also "more work" for some developers would have to do, and they'd have to do it "right now". >So when will we do it? I definitely do like the idea of getting to 64-bit time_t on sparc64 before 5.2-release, but there is no question that it adds to the work necessary before "5.x" becomes "5.x-stable". If we are going to do it, we should talk as if we are going to do it "Right Now", or we should admit that it must wait until 6.0-current. I am willing to go through the same steps that you went through to get my one (1) sparc64 system to be running with 64-bit timestamps. I'm willing to recompile all the ports on mine. However, I don't really use my sparc64 system for all that much, and I can afford to erase the disk and start over if this really botches things up. And even if everything that I do works fine, that won't be much of a test. There is a lot of stuff that I do NOT do which someone would be doing if they used a sparc64 system as their primary desktop machine. So I am willing to try to do a 64-bit time_t on my one system, but only if there is a list of others who are going to do the same thing. We're only going to get from "here" to "there" if we start working on it, and we must see multiple developers stepping up Right Now who are willing to do that work (even if it's just testing-work, it has to be done). Otherwise, let's concentrate on getting to 5.x-stable, and put off all talk of 64-bit time_t's until we create 6.0-current. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu