On Thu, Jul 12, 2018 at 2:42 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Fri, Jul 6, 2018 at 1:43 PM Arnd Bergmann arnd@arndb.de wrote:
On Fri, Jul 6, 2018 at 1:56 AM, Deepa Dinamani deepa.kernel@gmail.com wrote:
On Thu, Jul 5, 2018 at 3:21 PM, Christoph Hellwig hch@infradead.org wrote:
On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
It would be easy to rename compat_time_t, compat_timespec and compat_timeval to something else if we could come up with a good name for them (we already have too many variants of each of them though, otherwise we end up being more confusing rather than less).
legacy_time_t etc.?
I think it should have '32' in the name, otherwise it might lead to confusion regarding the size, as we also need legacy types that use 'long' (either 32-bit or 64-bit) seconds, besides the modern types that are always 64-bit.
In the previous patches, we introduced in the uapi
__kernel_timespec: always 64-bit (both seconds and nanoseconds) __kernel_old_timeval: replaces timeval (variable 'long' seconds/nanoseconds)
The __kernel_ prefix here signifies structures that are used in the uapi headers and are possibly included in user space but must not conflict with user space defined types like 'timeval' that can use either 'long' or 'long long' seconds in user space.
I would suggest we use __kernel_old_timespec for the equivalent timespec variant (long/long) for consistency. I originally thought we wouldn't need that one, but now it looks more likely that we do. I still think we won't need a 64-bit '__kernel_timeval' type, but it depends on what we do about getrusage(), getitimer() and adjtimex().
For the pure 32-bit types, I'd prefer 'old' over 'legacy', which is similar to the existing __kernel_old_dev_t, __kernel_gid_t, and __kernel_old_uid_t types, but we don't need the __kernel_ prefix because we would not use them in uapi headers.
I don't see a need for replacing compat_time_t right now (I may be missing something I had in mind earlier), but for timespec/timeval/itimerspec, how about old_timespec32, old_timeval32 and old_itimerspec32 to replace compat_timespec, compat_timeval and compat_itimerspec?
For itimerval, we probably need a __kernel_old_itimerval, but no __kernel_itimerval or old_itimerval, similar to what we do for timeval.
Arnd