On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
> socket timestamp options.
> These are the y2038 safe versions of the SO_TIMESTAMP_OLD
> and SO_TIMESTAMPNS_OLD for all architectures.
>
> Note that the format of scm_timestamping.ts[
On Tue, Jan 8, 2019 at 8:37 AM Willem de Bruijn
wrote:
>
> On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
> >
> > The series introduces new socket timestamps that are
> > y2038 safe.
> >
> > The time data types used for the existing socket
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
> socket timestamp options.
> These are the y2038 safe versions of the SO_TIMESTAMP_OLD
> and SO_TIMESTAMPNS_OLD for all architectures.
>
> Note that the format of scm_timestamping.ts[
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
> This is the y2038 safe versions of the SO_TIMESTAMPING_OLD
> for all architectures.
>
> Signed-off-by: Deepa Dinamani
> Cc: ch...@zankel.net
> Cc: fenghua...@intel.com
> Cc: r.
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote:
>
> The series introduces new socket timestamps that are
> y2038 safe.
>
> The time data types used for the existing socket timestamp
> options: SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING
> are not y2038 safe. The series introduces SO_TIM
> 3 reasons for not doing this:
>
> 1. We do not want to break userspace. If we move this to
> linux/socket.h all the userspace programs now have to include
> linux/socket.h or get this definition through a new libc.
> 2. All the socket options are together in the file asm/socket.h. It
> doesn't se
On Fri, Dec 14, 2018 at 8:07 PM Deepa Dinamani wrote:
>
> > > diff --git a/arch/alpha/include/uapi/asm/socket.h
> > > b/arch/alpha/include/uapi/asm/socket.h
> > > index 00e45c80e574..352e3dc0b3d9 100644
> > > --- a/arch/alpha/include/uapi/asm/socket.h
> > > +++ b/arch/alpha/include/uapi/asm/socke
> This did not address yet the previous comments on consistency and
> unnecessary code churn.
>
> The existing logic to differentiate SO_TIMESTAMP from SO_TIMESTAMPNS
> in both tcp_recv_timestamp and __sock_recv_timestamp is
>
> if (sock_flag(sk, SOCK_RCVTSTAMP)) {
> if (sock_flag(sk, SOCK_
On Tue, Dec 11, 2018 at 3:30 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
> This is the y2038 safe versions of the SO_TIMESTAMPING_OLD
> for all architectures.
>
> Signed-off-by: Deepa Dinamani
> Cc: ch...@zankel.net
> Cc: fenghua...@intel.com
> Cc: r.
On Tue, Dec 11, 2018 at 3:30 PM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
> socket timestamp options.
> These are the y2038 safe versions of the SO_TIMESTAMP_OLD
> and SO_TIMESTAMPNS_OLD for all architectures.
>
> Note that the format of scm_timestamping.ts[
On Fri, Nov 30, 2018 at 5:43 PM Deepa Dinamani wrote:
>
> On Sun, Nov 25, 2018 at 6:33 AM Willem de Bruijn
> wrote:
> >
> > On Sun, Nov 25, 2018 at 12:28 AM Deepa Dinamani
> > wrote:
> > >
> > > > > > + if (
On Fri, Nov 30, 2018 at 5:38 PM Deepa Dinamani wrote:
>
> On Sat, Nov 24, 2018 at 7:59 PM Willem de Bruijn
> wrote:
> >
> > On Sat, Nov 24, 2018 at 3:58 AM Deepa Dinamani
> > wrote:
> > >
> > > SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING opti
> > > The existing timestamp options: SO_TIMESTAMP* fail to provide proper
> > > timestamps beyond year 2038 on 32 bit ABIs.
> > > But, these work fine on 64 bit native ABIs.
> > > So now we need a way of updating these timestamps so that we do not
> > > break existing userspace: 64 bit ABIs should
> > > > 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, thes
On Sun, Nov 25, 2018 at 12:28 AM Deepa Dinamani wrote:
>
> > > > + if (type == SO_TIMESTAMP_NEW || type == SO_TIMESTAMPNS_NEW)
> > > > + sock_set_flag(sk, SOCK_TSTAMP_NEW);
> > > > + else
> > > > + sock_reset_flag(sk, SOCK_TSTAMP_NEW);
> > > > +
> > >
> > >
On Sat, Nov 24, 2018 at 10:59 PM Willem de Bruijn
wrote:
>
> On Sat, Nov 24, 2018 at 3:58 AM Deepa Dinamani wrote:
> >
> > Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
> > socket timestamp options.
> > These are the y2038 safe versions o
On Sat, Nov 24, 2018 at 3:58 AM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
> This is the y2038 safe versions of the SO_TIMESTAMPING_OLD
> for all architectures.
>
> Signed-off-by: Deepa Dinamani
> Cc: ch...@zankel.net
> Cc: fenghua...@intel.com
> Cc: r.
On Sat, Nov 24, 2018 at 3:58 AM Deepa Dinamani wrote:
>
> Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
> socket timestamp options.
> These are the y2038 safe versions of the SO_TIMESTAMP_OLD
> and SO_TIMESTAMPNS_OLD for all architectures.
>
> Note that the format of scm_timestamping.ts[
On Sat, Nov 24, 2018 at 3:58 AM Deepa Dinamani wrote:
>
> SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING options, the
> way they are currently defined, are not y2038 safe.
> Subsequent patches in the series add new y2038 safe versions
> of these options which provide 64 bit timestamps on all
> a
19 matches
Mail list logo