On Sun, Nov 25, 2018 at 5:52 AM Deepa Dinamani deepa.kernel@gmail.com wrote:
On Sat, Nov 24, 2018 at 11:38 AM Willem de Bruijn willemdebruijn.kernel@gmail.com wrote:
On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani deepa.kernel@gmail.com wrote:
The new type is meant to be used as a y2038 safe structure to be used as part of cmsg data. Presently the SO_TIMESTAMP socket option uses struct timeval for timestamps. This is not y2038 safe. Subsequent patches in the series add new y2038 safe socket option to be used in the place of SO_TIMESTAMP_OLD. struct sock_timeval will be used as the timestamp format at that time.
struct sock_timeval also maintains the same layout across 32 bit and 64 bit ABIs.
Signed-off-by: Deepa Dinamani deepa.kernel@gmail.com
include/uapi/linux/time.h | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h index 04d5587f30d3..106f9398c285 100644 --- a/include/uapi/linux/time.h +++ b/include/uapi/linux/time.h @@ -70,6 +70,11 @@ struct __kernel_old_timeval { }; #endif
+struct sock_timeval {
long long tv_sec;long long tv_usec;should these use fixed-width type __u64?
We have avoided using __u64/__s64 types for time types in uapi. I think we did this for portability reasons. Although this new type might not be required to be interpreted in libc, I would prefer for this to be long long. If there is a strong preference then I can change it.
I think we want signed types to keep it closer to what we have today with 'timeval'. as long as linux/types.h is included first (it is).
Between __s64 or long long, I don't think it makes a difference, so let's just go with Willem's suggestion. We already rely on 'long long' being exactly 64 bit wide in 'struct __kernel_timespec' as well.
We could however debate whether 'sock_timeval' should be visible to user space in linux/tme.h like this, or if it should be put in a namespace like '__kernel_sock_timeval' to ensure it won't conflict with user space headers defining a type of the same name.
Arnd