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()
CREATE sleep64() (takes timeval64)
typedef int64_t time64_t;
struct timeval64 {
time64_t tv_sec;
int64_t tv_frac; /* N/2^63 fractional */
};
typedef struct timeval64 timespec64;
struct itimerval64 {
struct timeval64 it_interval;
struct timeval64 it_value;
int64_t it_resolution; /* N/2^63 fractional (ro) */
}
#define TIMEFRAC 0x4000000000000000LL
I understand some people may want this to be unsigned and
0xF[63] 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 stat64(), 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 --unix64 (sets __UNIX_API64__)
gcc --unix32 (unsets __UNIX_API64__) (default)
Then our system include files would do this (in appropriate places):
#ifdef __UNIX_API64__
#define stat stat64
#define ... (etc)
#define time_t time64_t
#define timeval timeval64
#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 --unix64 the default.
TIMEVAL64 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.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
(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())
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
