[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-+ZiBR+VFzDnKOKPBCuNF_wbAe6goNO8KXYQH105Sg=0g@mail.gmail.com>
Date: Sun, 25 Nov 2018 09:38:41 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Deepa Dinamani <deepa.kernel@...il.com>
Cc: David Miller <davem@...emloft.net>,
LKML <linux-kernel@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
y2038 Mailman List <y2038@...ts.linaro.org>,
jejb@...isc-linux.org, ralf@...ux-mips.org, rth@...ddle.net,
linux-alpha@...r.kernel.org, linux-mips@...ux-mips.org,
linux-parisc@...r.kernel.org, linux-rdma@...r.kernel.org,
sparclinux@...r.kernel.org
Subject: Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]_NEW
> > > > Same for the tcp case above, really, and in the case of the next patch
> > > > for SO_TIMESTAMPING_NEW
> > >
> > > That naming convention, ..._2038, is not the nicest, of course. That
> > > is not the relevant bit in the above comment.
>
> it could be __sock_recv_timestamp64().
> But, these timestamps should be doing exactly the same thing as the
> old ones and I thought it would be nicer to keep the same code path.
> I can change it to as per above.
Please minimize code changes. It breaks git blame and longer patches
are harder to review.
In this specific case, from a readability point of view, I find new functions
that map one-to-one onto the new interfaces also more readable than
deeper nested branches in place.
> > So we introduce new y2038 safe timestamp options for 32 bit ABIs. We
> > assume that 32 bit applications will switch to new ABIs at some point,
> > but leave the older timestamps as is.
> > I can update the commit text as per above.
>
> We have been avoiding adding timeval64 timestamps to discourage users
> from using these types in the interfaces.
> We want to keep all the uapi time interfaces to use __kernel_*
> interfaces. And, we already provide __kernel_timespec interface for
> such instances.
> But, in this case we do not have an option. So we introduce a type
> specific to sockets.
This structure just holds a timestamp. It does not seem socket specific.
I don't mean to bikeshed the naming point too much, but timeval_ll or
so may be more representative than tying it to a socket.
As for the general naming, xxx64 or xxx2038 are more descriptive than xxx_NEW.
Powered by blists - more mailing lists