> > > > 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.
