Hi Deepa,
On Tue, 28 Feb 2017 11:07:02 -0800, Deepa Dinamani deepa.kernel@gmail.com wrote :
I've discussed the kernel side for "Y2038-incompatible socket timestamping" with Deep a while ago, and I think we came to a new conclusions for what would be the best approach. I'll let her comment here.
There is a small error in the way SO_TIMESTAMPING is described below:
SO_TIMESTAMPING uses an integer bitfield which is not sensitive to time bit-size.
SO_TIMESTAMPING uses the below struct as its cmsg data: struct scm_timestamping { struct timespec ts[3]; };
I think we're talking about two different things: the integer bitfield I am talking about is the argument to setsockopt, described as such in Documentation/networking/timestamping.txt; the struct scm_timestamping you're talking about is the ancillary data read through recvmsg() when some SO_TIMESTAMPING options were set.
As far as recvmsg / sendmsg / cmsg are concerned, I /think/ there are no dependencies per se on time_t size; it only comes into play when/if CMSG_DATA() is type-cast to (a pointer to) a type which involves time_t, and such casts are done at application, not GLIBC, level.
This is AFAICT the case for the struct scm_timestamp from Linux is not (re)defined by GLIBC; application code which uses this struct will have taken it from Linux directly (and will have to be consistent re time_t between its Linux and GLIBC usage).
Timestamp options can also be differentiated based on the length argument in the cmsg. But, like the timeout options, since we do not want to rely on the lengths of the data, we agree that all the timestamping options will have 64 bit time_t versions like you mention.
Kernel will use a macro that Arnd suggested:
#define SO_TIMESTAMPNS ((sizeof(time_t) > sizeof(__kernel_long_t)) ? SO_TIMESTAMPNS64 : SO_TIMESTAMPNS32)
Your comments on SO_RCVTIMEO and SO_SNDTIMEO are consistent with what we had agreed upon before.
-Deepa
Thanks for your comments!
Cordialement, Albert ARIBAUD 3ADEV