It's come to my attention that a good deal of software uses
SO_TIMESTAMP (the socket option for receiving timestamps as control
messages attached to datagrams), whose definition changes for time64.
Without any further measures, it fails with ENOPROTOOPT on pre-5.1
kernels. Some programs handle this gracefully; others treat it as a
hard error. Apparently it's old enough, and widely available enough on
non-Linux, that it's fairly "reasonable" to just assume it works.

Since otherwise this looks like it's going to be a big breaking part
of the time64 release, I'm strongly leaning towards emulating
SO_TIMESTAMP (and SO_TIMESTAMPNS) for pre-5.1 kernels. This involves
converting the setsockopt/getsockopt calls to use the old option as a
fallback, but more importantly, having recvmsg scan and translate
received control messages. A draft of the patch is attached.

Since recvmsg can't distinguish between being called by a time32
binary (that intentionally requested SO_TIMESTAMP_OLD) and being
called by a time64 binary (that got SO_TIMESTAMP_OLD as a fallback),
it doesn't replace the old control message (this couldn't be done
in-place anyway, since the new one is larger) but appends it. Programs
running on pre-5.1 kernels, and all legacy time32 callers, will then
see both SCM_TIMESTAMP_OLD and SCM_TIMESTAMP[_NEW] control messages,
assuming both fit (if not, perhaps we should set MSG_CTRUNC flag like
the kernel would).

The related SO_TIMESTAMPING option is significantly harder to emulate
in a feature-complete manner, since it allows SCM_TIMESTAMPING to be
sent as a control message on a per-sendmsg basis, to control send
timestamp generation. A feature-incomplete version could be done just
like the other two, but it's not clear how beneficial that would be;
from my research so far (Debian Code Search, mostly, after some
initial reports of problems) it seems that SO_TIMESTAMPING is pretty
much always treated as a feature that might or might not be present or
work, and that absence is non-fatal. This makes sense because it's a
lot newer and seems Linux-specific.

One issue I've not mentioned yet is recvmmsg, which is an utter mess.
The O(1)-space emulation approach that works for recvmsg becomes O(n)
with recvmmsg, since there's nowhere to keep the original
msg_controllen for each msghdr. This means we need to limit vlen,
emulate it with recvmsg in a loop, or limit vlen in each loop
iteration but loop until the whole requested vlen is completed or
other exit conditions occur. My leaning would be just calling recvmmsg
in a loop since this whole function is such a mess.

Thoughts? Any potential problems with the attached?

Rich