Same for the tcp case above, really, and in the case of the next patch for SO_TIMESTAMPING_NEW
That naming convention, ..._2038, is not the nicest, of course. That is not the relevant bit in the above comment.
it could be __sock_recv_timestamp64(). But, these timestamps should be doing exactly the same thing as the old ones and I thought it would be nicer to keep the same code path. I can change it to as per above.
Please minimize code changes. It breaks git blame and longer patches are harder to review.
In this specific case, from a readability point of view, I find new functions that map one-to-one onto the new interfaces also more readable than deeper nested branches in place.
So we introduce new y2038 safe timestamp options for 32 bit ABIs. We assume that 32 bit applications will switch to new ABIs at some point, but leave the older timestamps as is. I can update the commit text as per above.
We have been avoiding adding timeval64 timestamps to discourage users from using these types in the interfaces. We want to keep all the uapi time interfaces to use __kernel_* interfaces. And, we already provide __kernel_timespec interface for such instances. But, in this case we do not have an option. So we introduce a type specific to sockets.
This structure just holds a timestamp. It does not seem socket specific. I don't mean to bikeshed the naming point too much, but timeval_ll or so may be more representative than tying it to a socket.
As for the general naming, xxx64 or xxx2038 are more descriptive than xxx_NEW.