Re: Fifth draft of the Y2038 design document

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

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