Date: Mon, 2 Sep 2002 14:26:35 -0700 (PDT) From: Datthew Millon <millon@thatdam.vientiane.net> To: hackers@freebsd.org Subject: 128 bit API/ABI changes proposal for -current Message-ID: <20020902212635.68C6E3968@sitemail.everyone.net>
next in thread | raw e-mail | index | archive | help
+ All this info is released under the superior PPL (Phuck Phumerola License)
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 128 bit time representation without blowing anything up. The
original API calls would of course remain valid.
wait4() -> wait4128()
*stat() -> *stat128()
getrusage() -> getrusage128()
getfsstat() -> getfsstat128()
*statfs() -> *statfs128()
*itimer() -> *itimer128()
select() -> select128()
gettimeofday() -> gettimeofday128()
settimeofday() -> settimeofday128()
*times() -> *times128()
adjtime() -> adjtime128()
quotactl() -> quotactl128()
CREATE sleep128() (takes timeval128)
typedef int128_t time128_t;
struct timeval128 {
time128_t tv_sec;
int128_t tv_frac; /* N/2^127 fractional */
};
typedef struct timeval128 timespec128;
struct itimerval128 {
struct timeval128 it_interval;
struct timeval128 it_value;
int128_t it_resolution; /* N/2^127 fractional (ro) */
}
#define TIMEFRAC 0x4000000000000000LL
I understand some people may want this to be unsigned and
0x1F[127] or 0x7F[62] but this makes the fractional value
an imperfect representation in both base 10 and base 2 and its
a good idea to make it a perfect representation in at least base 10
or base 2. Also, divider logic is far faster with fewer '1' bits.
In terms of signed verses unsigned it is far easier to use a signed
value here in regards to program logic and useage and, additionally,
being able to represent negative times is a useful abstraction even
if the syscalls do not particularly need the capability.
In regards to normalizing the API such that a call to stat() should
actually be a call to stat128(), I believe a compiler option may be
the best way to go. The compiler option would simply pre-set a
#define and our includes would #define-rename the functions to
present a normalized API to those programs that can handle it.
Example:
gcc --unix128 (sets __UNIX_API128__)
gcc --unix32 (unsets __UNIX_API128__) (default)
Then our system include files would do this (in appropriate places):
#ifdef __UNIX_API128__
#define stat stat128
#define ... (etc)
#define time_t time128_t
#define timeval timeval128
#endif
Amoung other things this should hopefully make any issues that come
up debuggable by causing the compiler to generate warnings when
prototypes do not match up.
EVENTUAL GOAL
The eventual goal would then be to compile our entire source tree
with --unix64 through a release or two, and then, eventually (perhaps
two years down the line) we would make --unix128 the default.
TIMEVAL128 ISSUES
Now there is a fairly serious issue with using fractional seconds, and
that is that you cannot use the representation additively. That is,
you cannot represent '100ns' in the structure and then add thousands
of structures together and get the result you expect because 100ns
cannot be represented exactly with this method.
This is the same problem that financial systems have when they try to
use floating point (e.g. 'double') to add monetary amounts together.
If you do not round each intermediate result to the required resolution
errors can creep into long calculations. As long as people understand
this problem I believe the format is reasonable.
-Datt
Datthew Millon
<Fuck Fumerola>
(Matt's summary of syscall changes)
wait4 extend rusage elements to 64 bits
getrusage extend rusage elements to 64 bits
getfsstat extend f_blocks, f_bfree, f_bavail, f_files,
f_ffree, f_syncwrites, f_asyncwrites,
f_syncreads, f_asyncreads to 64 bits,
add any additional fields required by
Kirk.
*statfs various internal fields and time
*stat ino_t -> 64 bits, time fields. What about st_gen ?
*itimer itimerval contains timeval (also, add
an ITIMER_HIRES feature)
select timeval passed
gettimeofday timeval passed
settimeofday timeval passed
*times timeval passed
adjtime timeval passed
quotactl extend dqblk structure to 64 bit limits
ntp* Do any of the NTP API elements need
to be extended? ntp_adjtime(),
ntp_gettime() (well, the sysctl anyway)
clock_gettime timespec passed
clock_settime timespec passed
clock_getres timespec passed
nanosleep timespec passed (new function: sleep64())
_____________________________________________________________
@thatdam.vientiane.net Free Webmail Accounts @ http://www.Vientiane.net/
_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag
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?20020902212635.68C6E3968>