Hi,
On 13 May 2014 10:02, Ley Foon Tan <lftan@xxxxxxxxxx> wrote:
> Use 64 bit time_t and clock_t as default. 32 bit users can provide
> an override to define these as "long" if needed.
>
> Signed-off-by: Ley Foon Tan <lftan@xxxxxxxxxx>
> ---
> include/uapi/asm-generic/posix_types.h | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
> index fe74fcc..3f0e613 100644
> --- a/include/uapi/asm-generic/posix_types.h
> +++ b/include/uapi/asm-generic/posix_types.h
> @@ -81,12 +81,22 @@ typedef struct {
> #endif
>
> /*
> + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
> + * define these as "long" if needed.
> + */
> +#ifndef __kernel_time_t
> +typedef long long __kernel_time_t;
> +#endif
> +
> +#ifndef __kernel_clock_t
> +typedef long long __kernel_clock_t;
> +#endif
I think having this as the first patch in the series will break
bisection for existing 32-bit arches. This needs to be done in such a
way that at no intermediate commit are __kernel_time_t or
__kernel_clock_t the wrong size for existing arches, e.g. by having a
first patch which makes the typedefs conditional but leaves them as
__kernel_long_t, and a final patch that changes the default after all
the arches have got their overrides in place.
Cheers
James
> +
> +/*
> * anything below here should be completely generic
> */
> typedef __kernel_long_t __kernel_off_t;
> typedef long long __kernel_loff_t;
> -typedef __kernel_long_t __kernel_time_t;
> -typedef __kernel_long_t __kernel_clock_t;
> typedef int __kernel_timer_t;
> typedef int __kernel_clockid_t;
> typedef char * __kernel_caddr_t;
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
