Matthew Dillon wrote:
> Well, then what we want is a new syscall vector, duplicate libraries,
> and a compiler option, and leave all the function names the same
> (which means no bintime but allows us to retain everything else).
> -current would release supporting both with the compiler option
> defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms,
> and then down the line the compiler option would default to --unix64
> on all platforms, and then down the line a little more the original
> syscall vector would become a compatibility option that most people
> leave out.
Argh! This is way overkill. It is *not* what I was advocating.
The time to do this is when we bump libc's major number, not duplicating
libraries etc. That's a worst case outcome especially when it isn't needed.
It would be far less disruptive to add an additional group of 64 bit
time aware API's that are optional and portable. Leave the standards-defined
API's alone.
For example, in your previous suggestion, you had:
typedef int64_t time64_t;
struct timeval64 {
time64_t tv_sec;
int64_t tv_frac; /* N/2^63 fractional */
};
#ifdef __UNIX_API64__
#define timeval timeval64
#endif
You simply *cannot do this* and remain posix compliant on 64 bit machines.
We do not just go and change posix api's just for the sake of leaving out a
"64" in a name. If you are going to modify code to use tv_frac, then you
may as well refer to it in a 'struct timeval64' and be done with it.
I suspect there would be far less confusion if they were not named so closely
to their standardized counterparts.
Changing code to work with --unix64 on 32 bit systems becomes useless
when we have 64 bit native systems, because we then need to un-port it..
(remember --unix64 changes struct timeval.tv_usec to .tv_frac, so code that
is "cleaned" to work on --unix64 will no longer compile on a native
64 bit posix compliant environment)
Maybe I'm getting all upset about nothing, but you are scaring the hell
out of me so far.
> The advantage of all of this is that the 32 bit code stays intact and
> compatible in both source and binary forms, which means no further
> disruption of -current, just a lot of ABI work on my part. I already
> did a dry run of the libc changes necessary and given the chance to
> adjust things incrementally (which can be done with this methodology),
> it's a lot of grunt work but nothing that I couldn't do in a few weeks.
Well, I'd like to see a working prototype before anything is committed.
Changes in this area are of massive importance to the whole project, so we
*must* get it right and agreed apon, or leave it alone. It would also be
really good if you could get some buy-in from the other *bsd/linux folks.
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
