[1/2] y2038: linux: Provide __mq_timedsend_time64 implementation

  On Feb 12 2020, Lukasz Majewski wrote:

> I've added the struct __timespec64 definition to
> ./include/bits/struct/timespec.h
>
>
> and I had build errors on ./include/time.h which uses struct
> __timespec64 massively.
> It requires explicit adding of #include
> <include/bits/struct/timespec.h> or <bits/struct/timespec.h>

This works for me:


Andreas.
  

Hi Andreas,

> On Feb 12 2020, Lukasz Majewski wrote:
> 
> > I've added the struct __timespec64 definition to
> > ./include/bits/struct/timespec.h
> >
> >
> > and I had build errors on ./include/time.h which uses struct
> > __timespec64 massively.
> > It requires explicit adding of #include
> > <include/bits/struct/timespec.h> or <bits/struct/timespec.h>  
> 

Apparently I had wrong paths.

> This works for me:
> 
> diff --git a/include/bits/types/struct_timespec.h
> b/include/bits/types/struct_timespec.h index c27417cfd5..de1cf44311
> 100644 --- a/include/bits/types/struct_timespec.h
> +++ b/include/bits/types/struct_timespec.h

The question is about naming convention -

include/bits/types/struct_timespec.h -> suggest that we do have here
the "internal" re-definition of struct timespec but IMHO we do
introduce another "internal type" - namely struct __timespec64

Hence the below code shall be put to:
include/bits/types/struct__timespec64.h 

to have the distinction between internally used struct timespec and
struct __timespec64 (which would be used explicitly on archs with
__WORDSIZE==32 (e.g. arm32, rv32)

Am I right here?

> @@ -1 +1,30 @@
> +#ifndef _STRUCT_TIMESPEC
>  #include <time/bits/types/struct_timespec.h>
> +
> +#ifndef _ISOMAC
> +# include <endian.h>
> +# if __TIMESIZE == 64
> +#  define __timespec64 timespec
> +# else
> +/* The glibc Y2038-proof struct __timespec64 structure for a time
> value.
> +   To keep things Posix-ish, we keep the nanoseconds field a 32-bit
> +   signed long, but since the Linux field is a 64-bit signed int, we
> +   pad our tv_nsec with a 32-bit unnamed bit-field padding.
> +
> +   As a general rule the Linux kernel is ignoring upper 32 bits of
> +   tv_nsec field.  */
> +struct __timespec64
> +{
> +  __time64_t tv_sec;         /* Seconds */
> +#  if BYTE_ORDER == BIG_ENDIAN
> +  __int32_t :32;             /* Padding */
> +  __int32_t tv_nsec;         /* Nanoseconds */
> +#  else
> +  __int32_t tv_nsec;         /* Nanoseconds */
> +  __int32_t :32;             /* Padding */
> +#  endif
> +};
> +# endif
> +#endif
> +
> +#endif
> diff --git a/include/time.h b/include/time.h
> index 73f66277ac..f806bd8f0f 100644
> --- a/include/time.h
> +++ b/include/time.h
> @@ -6,7 +6,6 @@
>  # include <bits/types/locale_t.h>
>  # include <stdbool.h>
>  # include <time/mktime-internal.h>
> -# include <endian.h>
>  # include <time-clockid.h>
>  # include <sys/time.h>
>  
> @@ -60,29 +59,6 @@ extern void __tzset_parse_tz (const char *tz)
> attribute_hidden; extern void __tz_compute (__time64_t timer, struct
> tm *tm, int use_localtime) __THROW attribute_hidden;
>  
> -#if __TIMESIZE == 64
> -# define __timespec64 timespec
> -#else
> -/* The glibc Y2038-proof struct __timespec64 structure for a time
> value.
> -   To keep things Posix-ish, we keep the nanoseconds field a 32-bit
> -   signed long, but since the Linux field is a 64-bit signed int, we
> -   pad our tv_nsec with a 32-bit unnamed bit-field padding.
> -
> -   As a general rule the Linux kernel is ignoring upper 32 bits of
> -   tv_nsec field.  */
> -struct __timespec64
> -{
> -  __time64_t tv_sec;         /* Seconds */
> -# if BYTE_ORDER == BIG_ENDIAN
> -  __int32_t :32;             /* Padding */
> -  __int32_t tv_nsec;         /* Nanoseconds */
> -# else
> -  __int32_t tv_nsec;         /* Nanoseconds */
> -  __int32_t :32;             /* Padding */
> -# endif
> -};
> -#endif
> -
>  #if __TIMESIZE == 64
>  # define __itimerspec64 itimerspec
>  #else
> 
> Andreas.
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
  

On Feb 12 2020, Lukasz Majewski wrote:

> The question is about naming convention -
>
> include/bits/types/struct_timespec.h -> suggest that we do have here
> the "internal" re-definition of struct timespec but IMHO we do
> introduce another "internal type" - namely struct __timespec64
>
> Hence the below code shall be put to:
> include/bits/types/struct__timespec64.h 

That would be ok with me either way.

Andreas.
  

Hi Andreas,

> On Feb 12 2020, Lukasz Majewski wrote:
> 
> > The question is about naming convention -
> >
> > include/bits/types/struct_timespec.h -> suggest that we do have here
> > the "internal" re-definition of struct timespec but IMHO we do
> > introduce another "internal type" - namely struct __timespec64
> >
> > Hence the below code shall be put to:
> > include/bits/types/struct__timespec64.h   
> 
> That would be ok with me either way.
> 
> Andreas.
> 

The same code put into include/bits/types/struct___timespec64.h file
requires having the explicit #include in ./include/time.h (and
mqueue.h).

However, it works correctly (i.e. is included automatically) only when
put into include/bits/types/struct_timespec.h

I need to investigate it further...


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de