: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).
This is wishful thinking, which I will elaborate on below.
: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
Ok, now wait a second. First of all our time_t problems do not start
in 2038. THEY ARE ALREADY HERE. A 32 bit time_t is an unusable
representation for a growing number of applications. Simulations,
forward looking contract time/date representation, databases, hell
even my USENET news server uses a 64 bit time representation internally.
Second, by far the most important reason for giving 32 bit platforms
a 64 bit time capability is software portability, and that is an issue
NOW. People who develop software on 32 bit platforms do not have
universal access to 64 bit platforms in order to ensure that their
code works. Every single application I've written that uses time_t
heavily has required modifications when ported to a 64 bit platform,
even though I tried to take into account 64 bit time_t's in the
development of the software.
Being able to write an application that uses 64 bit time_t's on a 32
bit platform now is therefore an important goal.
Third, you have a very short term view of the longevity of software.
Software I wrote 10 years ago is likely to still be in operation in
2038. One of the new products I am working on uses PC/104 technology
and some of those units are almost guarenteed to still be in operation
in 2037. When 2037 comes rolling around I'm not likely to want to pull
out the "old source" and try to "make it work".
This is a problem for me *NOW*, not in 2038. But NOW.
Forth, FreeBSD is used heavily in the embedded world and the intention
seems to be to make it even more useable. A good chunk of the embedded
world will almost certainly still be using 32 bit platforms in 2038.
64 bits is great, but 64 bits eats a great deal of electrical power.
This is why you still see little 8 bit cpus in the embedded world
today. 32 bit platforms are likely to be in major use in 2038.
: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.
This is not what I proposed. I proposed adding new system calls to
completely and permanently fix all of our outstanding issues and then
providing a compiler option to allow developers to select which API
they want presented.
I'm not sure what the correct solution is but I am sure that we
need one, and that we should do at least the kernel bits to support
a solution for the 5.0 release. But I will tell you something... I
am not a fan of basic system data types changing sizes whether you
happen to be running your software on a 32 bit platform or a 64 bit
platform. Our off_t works extremely well simply because it's big
enough and because it is the same across all platforms. Until we
are able to supply kernel support for similar functionality with other
data types - time specifications, inodes, block numbers, and so forth,
our API and ABI will remain broken in my view.
: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.
Again, nothing I proposed would have any effect on our ports. All of
my proposals to date are designed to avoid screwing up -current.
Perhaps you need to read my posting(s) a bit more carefully.
I am still completely open to other solutions, including creating a
new syscall vector and allowing a native 32 or 64 bit API to be
chosen as a compile-time option, but I do not believe that putting
off the whole affair is any sort of solution.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:Also, hackers@ is really not the place for this.
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
:"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
