[PATCH v3 3/4] tests/sockopt-timestamp: Don't test old timestamps if unsupported

[Dmitry V. Levin]

On Mon, Mar 16, 2020 at 05:02:00PM -0700, Alistair Francis wrote:
> On Sun, Mar 15, 2020 at 9:35 AM Dmitry V. Levin wrote:
> > On Fri, Mar 06, 2020 at 06:22:22PM -0800, Alistair Francis wrote:
> > > On new 32-bit architectures (like RV32) the kernel defines SO_TIMESTAMP
> > > to SO_TIMESTAMP_NEW (see include/uapi/asm-generic/socket.h:133).
> > > Although SO_TIMESTAMP_OLD still exists it returns data that doesn't fit
> > > into the struct timeval as the old timestamp isn't 64-bit (y2038 safe).
> > >
> > > To fix this let's skip the test cases if SO_TIMESTAMP is the same as
> > > SO_TIMESTAMP_NEW. Unfortunately as SO_TIMESTAMP is defined with a one
> > > line if statement (? :) we can't use preprocess defines and instead need
> > > to just skipt the tests.
> >
> > Sorry, did you say that rv32 kernel can send SO_TIMESTAMP_OLD (and also
> > SO_TIMESTAMPNS_OLD with SO_TIMESTAMPING_OLD) control messages containing
> > 32-bit time_t, in contradiction with remaining rv32 types where time_t
> > is 64-bit?
> 
> I think so.
> 
> > This would be so ridiculous for a new architecture that I cannot believe
> > rv32 kernel behaves this way.
> 
> Why? There are still lots of syscalls that use a 32-bit time_t.

Really?  Besides those that deal with struct rusage and socket control
messages?  No, I don't think so.

> I sent a new patch series with a new version of this patch as well, so
> you can see what I am doing there.

According to that series, other syscalls do not use 32-bit time_t on rv32.

I suppose rv32 implements struct rusage using 32-bit time_t for
consistency with other 32-bit architectures.

Unlike struct rusage, SO_TIMESTAMP*_OLD are deprecated by
SO_TIMESTAMP*_NEW because SO_TIMESTAMP/SO_TIMESTAMPNS/SO_TIMESTAMPING
are defined to the corresponding SO_TIMESTAMP*_NEW values on rv32.

So my question is, why rv32 implements
SO_TIMESTAMP_OLD/SO_TIMESTAMPNS_OLD/SO_TIMESTAMPING_OLD at all,
and why it implements these control messages using 32-bit time_t?


-- 
ldv