On Tue, Jan 12, 2021 at 8:05 AM Michael Kerrisk (man-pages)
<mtk.manpages@xxxxxxxxx> wrote:
>
> Hi Florian,
>
> On Tue, 12 Jan 2021 at 13:33, Florian Weimer <fweimer@xxxxxxxxxx> wrote:
> >
> > * Willem de Bruijn:
> >
> > > From: Willem de Bruijn <willemb@xxxxxxxxxx>
> > >
> > > Expand the epoll_wait page with epoll_pwait2, an epoll_wait variant
> > > that takes a struct timespec to enable nanosecond resolution timeout.
> > >
> > > int epoll_pwait2(int fd, struct epoll_event *events,
> > > int maxevents,
> > > const struct timespec *timeout,
> > > const sigset_t *sigset);
> >
> > Does it really use struct timespec? With 32-bit times on most 32-bit
> > targets?
>
> The type inside the kernel seems to be:
>
> [[
> SYSCALL_DEFINE6(epoll_pwait2, int, epfd, struct epoll_event __user *, events,
> int, maxevents, const struct __kernel_timespec __user
> *, timeout,
>
> struct __kernel_timespec {
> __kernel_time64_t tv_sec; /* seconds */
> long long tv_nsec; /* nanoseconds */
> };
> ]]
>
> So, 64 bits by the look of things.
Yes. The C library is expected to define the function as shown here,
and internally call the syscall with __kernel_timespec.
This is similar to modern time64 variants of other timespec syscall,
such as ppoll.
For 64-bit archs like x86_64, ppoll maps onto sys_ppoll with native
__kernel_timespec.
For 32-bit archs like x86, the library is expected to call new
ppoll_time64 , with the same type.
On 32-bit archs, the existing ppoll maps onto a syscall that expects
the __old_timespec32. Legacy C libraries and direct callers will
continue to call this.
For the new epoll_pwait2 syscall we do not add this non-y2038
compliant version, as there is no need for backward compatibility with
legacy users.
