Re: [RFC PATCH] media: videodev2.h: include <linux/time.h> instead of <sys/time.h>

[Masahiro Yamada]

Hi Arnd,

On Tue, Oct 8, 2019 at 12:26 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Mon, Oct 7, 2019 at 6:10 AM Masahiro Yamada
> <yamada.masahiro@xxxxxxxxxxxxx> wrote:
> >
> > Currently, linux/videodev.h is excluded from the UAPI header test since
> > it is not self-contained. Building it for user-space would fail.
> >
>
> >
> > Replacing <sys/time.h> with <linux/time.h> solves it, and allow more
> > headers to join the UAPI header test.
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
> > ---
> >
> > I am not 100% sure about the compatibility
> > between <sys/time.h> and <linux/time.h>, hence RFC.
> >
> > But, if they were not compatible,
> > I guess it would have broken already.
> >
> > I CCed Arnd Bergmann, who might have a better insight.
> >
> > A related comment is here:
> > https://lkml.org/lkml/2019/6/4/1046
>
> I don't think this can work, there are multiple problems here:
>
> * linux/time.h is still incompatible with sys/time.h, so any application
>   tries to include both sys/time.h and linux/videodev2.h now also
>   gets the compile-time error.

You are right.
I am so stupidly screwed up. Palm face...

Please ignore this patch,
and thank you for your expert comments!


>
> * The definition of 'struct timespec' in the kernel headers may in
>   fact be different from the one in the libc, and we do want to use
>   the one from the C library here, otherwise different parts of the
>   application may use incompatible struct layouts.
>
> Fixing this correctly depends on one of the remaining y2038
> patches that we still have to revisit. There are two aspects that
> we should address:
>
> 1. The v4l subsystem needs to be changed to handle both the
>     old and the new 32-bit layout for timespec (and timeval). Both
>     Hans and I have created patches for this in the past, but they
>     were never completed and merged.
>
> 2. The definition of 'struct timespec' in the kernel headers needs
>    to be removed after every user of this struct is gone from
>    the kernel. In internal kernel code, the replacement is
>    timespec64 or ktime_t, and in user space interfaces, the
>    correct replacement is one of __kernel_timespec (the 64-bit
>    version), __kernel_old_timespec (the traditional layout) or
>    timespec (from the libc headers).
>
>         Arnd



--
Best Regards

Masahiro Yamada