Thread (43 messages) flat view 43 messages, 8 authors, 2018-02-13

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

From: Miroslav Lichvar <mlichvar@redhat.com>
Date: 2018-01-25 09:12:30
Also in: intel-wired-lan

On Fri, Jan 19, 2018 at 06:09:15PM -0800, Richard Cochran wrote:
On Fri, Jan 19, 2018 at 04:15:46PM -0500, Willem de Bruijn wrote:
quoted
quoted
+               if (cmsg->cmsg_len != CMSG_LEN(sizeof(ktime_t)))
+                       return -EINVAL;
I don't see any existing reference to ktime_t in include/uapi. Just use a s64?
Agreed.  I didn't see the point of switching to ktime, either.
Do I understand it correctly that no other interface is using
nanoseconds since 1970? We probably don't have to worry about year
2262 yet, but wouldn't it be better to make it consistent with the
timestamping API using timespec? Or is it just better to avoid the
64/32-bit mess of time_t?

-- 
Miroslav Lichvar
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help