Hi Arnd,
On Thu, 14 Jul 2016 13:39:13 +0200, Arnd Bergmann arnd@arndb.de wrote :
On Wednesday, July 13, 2016 7:38:25 PM CEST Deepa Dinamani wrote:
On Wed, Jul 13, 2016 at 1:40 PM, Deepa Dinamani deepa.kernel@gmail.com wrote:
[...] [...]
Another way of handling this would be to use the flags in sendmsg/recvmsg. Since cmsg is sent using these calls, at the time of call, sendmsg/recvmsg can indicate whether 64 bit time_t or 32 bit time_t is used. This will eliminate the need for new options and kernel need not depend on __USE_TIME_BITS64.
Good point, I had forgotten how we discussed that a while ago.
[...] [...]
But, if we are not using optlen here, then probably just using new numbers for timestamps also makes sense.
Forgot to note one more thing here. Since we are already using struct sizes for ioctls, shouldn't this be similar. So optlen should also be okay? Just as in the example Arnd pointed out above:
/* Set and get port timeout (struct timeval's) */ #define PPGETTIME _IOR(PP_IOCTL, 0x95, struct timeval) #define PPSETTIME _IOW(PP_IOCTL, 0x96, struct timeval)
I've added the netdev list and David Miller to Cc here, it seems either way would work, and I don't have a strong preference.
a) add a flag to recvmsg() that glibc always passes when called using __USE_TIME_BITS64 to handle reading the timestamps, and rely on the optlen value for SO_RCVTIMEO/SO_SNTTIMEO to decide how to interpret the data
b) handle all five sockopts using conditional option numbers and don't rely on the recvmsg() flag or optlen.
Using either a) or b) is probably better than a combination of them, so I've not listed that as another alternative.
To work around the header inclusion order problem we discussed earlier for approach b), I suppose we can do this using something like
#define SO_RCVTIMEO_TIME32 21 #define SO_RCVTIMEO_TIME64 53
#define SO_RCVTIMEO (__USE_TIME_BITS==64 ? SO_RCVTIMEO_TIME64 : SO_RCVTIMEO_TIME32)
where __USE_TIME_BITS is a macro defined by the libc. We cannot easily check for whether a macro is defined in a conditional expression, but I think the above should work, as long as we don't need use the value from assembler code.
Arnd
Seems like there was no reply on the netdev or libc-alpha lists or from David. I personally am not fond of relying on length to determine which variant of an argument we are dealing with, therefore I prefer option b over option a and will update the design doc accordingly.
Cordialement, Albert ARIBAUD 3ADEV