On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
On Thursday 05 November 2015 00:04:14 David Miller wrote:
As part of fixing y2038 problems, Arnd is going to have to make a new
version fo the AF_PACKET mmap() tpacker descriptors in order to extend
the time values to 64-bit.
So I want everyone to think about whether there are any other changes
we might want to make given that we have to make a v4 anyways.
Particularly, I am rather certain that the buffer management could be
improved. Some have complained that v3 is kinda awkward to use and/or
suboptimal is various ways.
I have taken a closer look at the actual timestamp data now, and noticed
that we use __u32 for both tp_sec and ts_sec in the user visible data.
This means that once we fix the internal implementation to use 64-bit
timestamps, we actually won't overflow until 2106 because the 2038 overflow
is only for signed 32-bit numbers as we have in 'struct timespec'.
So the good news is that we can keep the existing v1 through v3 formats
beyond 2038, but only as long as all user space that cares about the
value also interprets it as unsigned.
Right, I was just about to ask that. So we could just make a union in
AF_PACKET's UAPI for a single 64-bit variable (as in ktime_t) to fix that.
Best,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
