Re: [Y2038] [PATCH v2 08/10] fix get_timespec64() for y2038 safe compat interfaces

From: Ben Hutchings <ben.hutchings@codethink.co.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Y2038] [PATCH v2 08/10] fix get_timespec64() for y2038 safe compat interfaces
Date: Sun, 17 Dec 2017 23:51:47 +0000	[thread overview]
Message-ID: <1513554707.18523.299.camel@codethink.co.uk> (raw)
In-Reply-To: <CAK8P3a150Hw62O06Qfdty+9zTr1m_=jJ5PZRE0NZt1qpsTcJBg@mail.gmail.com>

On Fri, 2017-12-15 at 13:02 +0100, Arnd Bergmann wrote:
[...]
> - I had an idea to handle the copying of timespec/timeval with a
> one-size-fits-all
>   function and multiple wrappers around it, such as
> 
> enum user_ts_type {
>       USER_TS_TIMEVAL = 1,
>       USER_TS_32 = 2,
>       USER_TS_CLEARNSEC = 4,
>       USER_TS_NOCHECK = 8,
> };
[...]
> While working on the driver patches I encountered lots of different
> combinations of
> those that might be interesting here, so we could have wrappers for
> the most common
> ones and call get_timestruct() and put_timestruct() directly for the
> less common
> variations. Am I taking it too far here, or would that make sense?

I don't think I've reviewed enough time-handling stuff to know, but I
can certainly believe that this could be worth doing.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.