:Well, one thing that I would not be against is a clean divorce of the
:syscall layer and libc. That then gives us the freedom to implement
:alternative API selections etc at compile time pretty easily.
:
:I just really do not want to see this sort of thing turning up:
:
: time_t foo = time(0);
: printf("the time is %lld\n", (long long)foo); /* i386 compatability */
:
:.. because that hurts our 64 bit platforms down the road when long long
:becomes 128 bit. intmax_t/%j etc has similar problems as it then takes
:the native 64 bit time type (long) and converts it to a synthetic 128 bit
:type. ie: %j and intmax_t etc are just as bad.
:
:My first exposure to a unix OS had some pretty horrific stat structure
:versioning and evilness (svr4). It was a real nightmare, except you never
:got to wake up and discover that it was all over.
:
:I am not against providing 64 bit extentions for 32 bit systems, but it
:really needs to be done so that it all becomes a giant NOP when on native
:64 bit systems. Something like the large-file-summit API extensions that
:all magically go away after the transition period or when you get a chance
:to do a total ABI breakaway.
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
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.
If we do a clean cut of the ABI for the alpha, sparc, etc... for
things like ino_t, which I think we can get away with, then this all
becomes a big NOP on 64 bit platforms and eventually becomes a NOP
(only one library set and syscall vector is generated) on 32 bit
platforms. If we include the other structural changes... 64 bit
ino_t in *stat() for example, in only the --unix64 ABI, then
we encourage (but do not require) developers to migrate to the ABI.
printf("the time is %lld\n"...) is a problem that will *NEVER*
go away short of defining a format character to represent time_t
itself. The assumption that time_t is somehow tied to a 'long' is
broken, pure and simple. I actually think %j is workable, because
I don't know a single case of 'speed critical code' where you have a
*printf() call passing a time_t. It's very rare, and at least now
GCC will catch type size mismatches.
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.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
