Date: Sun, 14 Mar 2004 17:16:13 +1000 From: Stephen McKay <smckay@internode.on.net> To: Garance A Drosihn <drosih@rpi.edu> Cc: Stephen McKay <smckay@internode.on.net> Subject: Re: HEADS UP! MAJOR change to FreeBSD/sparc64 Message-ID: <200403140716.i2E7GDKa007204@dungeon.home> In-Reply-To: <p060204f5bc750679b827@[128.113.24.47]> from Garance A Drosihn at "Wed, 10 Mar 2004 18:00:07 %2B0000" References: <p060204f5bc750679b827@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 10th March 2004, Garance A Drosihn wrote: >The long-threatened change for FreeBSD/sparc64 has now been >committed. This changes time_t to be a 64-bit quantity, the >same as it is for the AMD64 and IA64 architectures. People >running FreeBSD/sparc64 *will* have to read the UPDATING.64BTT >file for instructions on how to safely build and install this >change. The change to 64-bit time is essential, of course, but I don't understand why it has to break backward compatibility. Surely you just allocate a bunch of new system call numbers (for the 64-bit variants) while keeping the old ones (so 32-bit time calls still work) and bump the version number of every library. What else is going on? (I don't have a Sparc or I'd join your experiment.) >This only affects freebsd-current, of course. Later we'll have >to decide the best upgrade method for people who make the jump >from RELENG_5_2 to the upcoming RELENG_5_3. I'm thinking of the "later" where i386 is changed to 64-bit time_t. If that's not backward compatible, you'll get no takers. Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403140716.i2E7GDKa007204>