Date: Mon, 02 Sep 2002 12:52:29 -0700 From: Peter Wemm <peter@wemm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: hackers@freebsd.org Subject: Re: 64 bit API/ABI changes proposal for -current Message-ID: <20020902195229.87E272A88D@canning.wemm.org> In-Reply-To: <200209021915.g82JFQ4h032492@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> About 34 system calls need work (with time changes), approximately
> 16 without time changes. I've included a summary at the end.
>
> The questions before us:
>
> * What to do about time representation.
>
> * Whether to create a new syscall vector or use the existing
> vector.
>
> I have thought long and hard about this and I now believe that we
> should keep our existing vector, even though it's become a real mess,
> at least through the release. This will also allow us to convert
> to a 64 bit time representation without blowing anything up. The
> original API calls would of course remain valid.
>
> wait4() -> wait464()
> *stat() -> *stat64()
> getrusage() -> getrusage64()
> getfsstat() -> getfsstat64()
> *statfs() -> *statfs64()
> *itimer() -> *itimer64()
> select() -> select64()
> gettimeofday() -> gettimeofday64()
> settimeofday() -> settimeofday64()
> *times() -> *times64()
> adjtime() -> adjtime64()
> quotactl() -> quotactl64()
Matt, I realize you have thought long and hard about this, but I want to
make a couple of points.
1) 32 bit i386 already has its fate sealed. AMD are switching to 64 bit,
and Intel are doing the same (either x86-64 or their own 64 bit environment,
depending on which rumors you listen to).
2) Many of these calls *are* 64 bit already on 64 bit platforms. Adding
an additional layer here just makes life harder when we 64 bit is the norm.
For example, get/settimeofday, *itimer, select, etc etc use timeval:
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* and microseconds */
};
and that, folks, is 64 bit on 64 bit platforms already.
3) 5.0 is not going to last till anywhere near year 2038. In the next year,
or two at tops, it is going to be perfectly clear what the future of common
64 bit hardware will look like
4) Changing time_t to 64 bit using long long on a native 32 bit platform
is a f*cking nightmare. I've tried this and it got very nasty very quickly.
5) Changing time_t to 64 bit is trivial on a native 64 bit platform. I
have done this on an ia64 machine. The sparc64 folks indicated they wanted
to do the same. Much of the work has been done already.
I worry that jumping in prematurely will leave us with a legacy issues that
will haunt us for year and years to come, while the linux folks laugh at
our pain and convoluted API's because they've already set their internal
time_t to 64 bit on their 64 bit platforms.
I urge folks to hold off just a bit longer so that we can get 5.x stable
and in shape and released without blowing up 50% of our ports due to long
long time_t problems. re@ is already having nightmares about 5.0, we do
not need this thrown into the mix yet. Especially when the right solution
will become more obvious as the 64 bit desktop machine dust settles.
Also, hackers@ is really not the place for this.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020902195229.87E272A88D>