From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miroslav Lichvar Subject: Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time. Date: Thu, 25 Jan 2018 10:12:25 +0100 Message-ID: <20180125091225.GG1169@localhost> References: <20180117230621.26074-1-jesus.sanchez-palencia@intel.com> <20180117230621.26074-2-jesus.sanchez-palencia@intel.com> <20180120020915.erlylrbsaejf7ufo@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Willem de Bruijn , John Stultz , Richard Cochran , =?utf-8?B?SmnFmcOtIFDDrXJrbw==?= , ivan.briano@intel.com, Network Development , henrik@austad.us, Jamal Hadi Salim , levi.pearson@harman.com, intel-wired-lan@lists.osuosl.org, Cong Wang , Thomas Gleixner , anna-maria@linutronix.de, Jesus Sanchez-Palencia To: Richard Cochran Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46146 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbeAYJMa (ORCPT ); Thu, 25 Jan 2018 04:12:30 -0500 Content-Disposition: inline In-Reply-To: <20180120020915.erlylrbsaejf7ufo@localhost> Sender: netdev-owner@vger.kernel.org List-ID: 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: > > > + 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