[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5f530323b66cd8c0055c5e642ef4eb035c53808.camel@codethink.co.uk>
Date:   Wed, 20 Nov 2019 22:30:18 +0000
From:   Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:     Arnd Bergmann <arnd@...db.de>, y2038@...ts.linaro.org
Cc:     Deepa Dinamani <deepa.kernel@...il.com>,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [Y2038] [PATCH 02/23] y2038: add __kernel_old_timespec and
 __kernel_old_time_t
On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote:
> The 'struct timespec' definition can no longer be part of the uapi headers
> because it conflicts with a a now incompatible libc definition. Also,
> we really want to remove it in order to prevent new uses from creeping in.
> 
> The same namespace conflict exists with time_t, which should also be
> removed. __kernel_time_t could be used safely, but adding 'old' in the
> name makes it clearer that this should not be used for new interfaces.
> 
> Add a replacement __kernel_old_timespec structure and __kernel_old_time_t
> along the lines of __kernel_old_timeval.
[...]
> --- a/include/uapi/linux/time_types.h
> +++ b/include/uapi/linux/time_types.h
> @@ -28,6 +28,11 @@ struct __kernel_old_timeval {
>  };
>  #endif
>  
> +struct __kernel_old_timespec {
> +	__kernel_time_t	tv_sec;			/* seconds */
Should this be __kernel_old_time_t for consistency?
Ben.
> +	long		tv_nsec;		/* nanoseconds */
> +};
> +
>  struct __kernel_sock_timeval {
>  	__s64 tv_sec;
>  	__s64 tv_usec;
-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom
Powered by blists - more mailing lists