> I think we want signed types to keep it closer to what we
> have today with 'timeval'. as long as linux/types.h is included
> first (it is).
>
> Between __s64 or long long, I don't think it makes a difference,
> so let's just go with Willem's suggestion. We already rely on
> 'long long' being exa
On Sun, Nov 25, 2018 at 5:52 AM Deepa Dinamani wrote:
> On Sat, Nov 24, 2018 at 11:38 AM Willem de Bruijn
> wrote:
> > On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani
> > wrote:
> > >
> > > The new type is meant to be used as a y2038 safe structure
> > > to be used as part of cmsg data.
> > > P
On Sat, Nov 24, 2018 at 11:38 AM Willem de Bruijn
wrote:
>
> On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani wrote:
> >
> > The new type is meant to be used as a y2038 safe structure
> > to be used as part of cmsg data.
> > Presently the SO_TIMESTAMP socket option uses struct timeval
> > for times
From: Willem de Bruijn
Date: Sat, 24 Nov 2018 14:37:42 -0500
> On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani wrote:
>> diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
>> index 04d5587f30d3..106f9398c285 100644
>> --- a/include/uapi/linux/time.h
>> +++ b/include/uapi/linux/tim
On Sat, Nov 24, 2018 at 4:00 AM Deepa Dinamani wrote:
>
> The new type is meant to be used as a y2038 safe structure
> to be used as part of cmsg data.
> Presently the SO_TIMESTAMP socket option uses struct timeval
> for timestamps. This is not y2038 safe.
> Subsequent patches in the series add ne
The new type is meant to be used as a y2038 safe structure
to be used as part of cmsg data.
Presently the SO_TIMESTAMP socket option uses struct timeval
for timestamps. This is not y2038 safe.
Subsequent patches in the series add new y2038 safe socket
option to be used in the place of SO_TIMESTAMP_
