[PATCH 6/7] socket: Add recvmsg timestamp test

[Adhemerval Zanella]

On 06/07/2021 06:29, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 05/07/2021 17:02, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>>>> +  do_test_send (&srv_addr, 1);
>>>>>> +  do_recvmsg (srv, false, NULL, 0, 0, 0);
>>>>>> +
>>>>>> +  /* If underlying kernel does not support   */
>>>>>> +  bool support_64_timestamp = support_socket_time64_timestamp (srv);
>>>>>> +
>>>>>> +  /* Enable the timestamp using struct timeval precision.  */
>>>>>> +  xsetsockopt (srv, SOL_SOCKET, SO_TIMESTAMP, &(int){1}, sizeof (int));
>>>>>
>>>>> Please use setsockopt here, nt the x wrapper, so that the ABI switches
>>>>> with time64 support.
>>>>
>>>> Currently it does not matter because SO_TIMESTAMP will be handled by
>>>> the kernel headers.
>>>
>>> With my __setsockopt64 patch, the time64 version of the test will use a
>>> different symbol.  This is what I meant.
>>
>> Yeah, I am not really convinced we do need such newer symbols that do
>> not correlate to 64-bit time_t syscall since I think it is *highly* 
>> unlikely kernel will 64-bit time_t facilities for multiplexed syscall
>> (and I would consider this a bug) without any guards or checking
>> if the program is using 32-bit time_t.
> 
> What about SO_VM_SOCKETS_CONNECT_TIMEOUT? 

Should we paper over all drivers or kernel features that do not have
proper 64-bit support?  If so it would add a quite complex multiplex
handling on some syscall (ioctl).  I would expect we will have quite
a few drivers out there which miss proper 64-bit support.

I added support for SO_TIMESTAMP{NS} because it is a features that 
uses libc defined datatype and we include the kernel headers directly
(so user has no opt-out).  I consider most driver as opt-in, where
users usually have to explicit include linux headers and they should 
be aware that if we want to use _TIME_BITS=64 they would need care to
use libc-defined datatypes.

But this is also error prone (and I would consider that drivers using
libc-define datatypes are as well) and I see your point.  I would
prefer if we avoid extra 64-bit symbols, but if you think we would
improve support in the future we can add as a conservative way.

> 
>> Florian, in any case *currently* this patch does not need to use
>> xsetsockopt.  I can adapt if your set get merged first.
> 
> Fine, go with xsetsockopt then.
> 
> Thanks,
> Florian
>