[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNASQ32R1-tqGDjnGYwMuOo=+SZMhzb7T39F-nKzr+=NaNQ@mail.gmail.com>
Date: Tue, 8 Oct 2019 01:47:58 +0900
From: Masahiro Yamada <yamada.masahiro@...ionext.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Pablo Neira Ayuso <pablo@...filter.org>,
Sam Ravnborg <sam@...nborg.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Hans Verkuil <hverkuil@...all.nl>
Subject: Re: [RFC PATCH] media: videodev2.h: include <linux/time.h> instead of <sys/time.h>
Hi Arnd,
On Tue, Oct 8, 2019 at 12:26 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, Oct 7, 2019 at 6:10 AM Masahiro Yamada
> <yamada.masahiro@...ionext.com> 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@...ionext.com>
> > ---
> >
> > 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
Powered by blists - more mailing lists