lkml.org 
[lkml]   [2019]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [Y2038] Question regarding support of old time interfaces beyond y2038
On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski <lukma@denx.de> 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

\
 
 \ /
  Last update: 2019-03-05 17:22    [W:0.072 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site