Date: Thu, 26 Feb 2004 18:23:10 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: John Polstra <jdp@polstra.com> Cc: freebsd-sparc64@freebsd.org Subject: RE: 64btt cvsup? Message-ID: <p0602048cbc640df37074@[128.113.24.47]> In-Reply-To: <XFMail.20040226122033.jdp@polstra.com> References: <XFMail.20040226122033.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> >> No. > ><ADVICE COST=0> >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 pretty disruptive. >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 problem. 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@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0602048cbc640df37074>