On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski <[email protected]> wrote: > From other discussion [4] - regarding the following system calls: > time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, alarm, > getitimer, setitimer, select, utime, utimes, futimesat, and > {old,new}{l,f,}stat{,64}. > > "These all pass 32-bit time_t arguments on 32-bit > architectures and are replaced by other interfaces (e.g. posix > timers and clocks, statx). C libraries implementing 64-bit time_t in > 32-bit architectures have to implement the handles by wrapping > around the newer interfaces."
1) We should be clear that most of these will continue to be supported as C library interfaces even if they are not system calls. Some of them are obsolete enough and/or rarely used enough that we might not bother (the older ways to set the system clock, for instance). 2) I know of one case where the new interfaces don't cover all of the functionality of the old ones: timers started by setitimer continue to run after an execve, timers started by timer_create don't. This means setitimer(ITIMER_VIRTUAL) can be used to impose a CPU time limit on a program you didn't write, and timer_create can't. If new kernels are not going to have setitimer as a primitive, we need some other way of getting the same effect. zw
