Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2014-01-21 Thread Catalin Marinas
On Tue, Jan 21, 2014 at 05:03:09PM +, H. Peter Anvin wrote:
> On 01/21/2014 08:58 AM, Catalin Marinas wrote:
> > BTW, could we not avoid the #if and always use __kernel_long_t? This
> > wouldn't break the user ABI.
> 
> Ah yes, this is the wrong version of the patchset.  I already gave that
> feedback and H.J. posted an update.  My bad.

Ah, I have to dig a newer version then.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2014-01-21 Thread H. Peter Anvin
On 01/21/2014 08:58 AM, Catalin Marinas wrote:
> 
> BTW, could we not avoid the #if and always use __kernel_long_t? This
> wouldn't break the user ABI.
> 

Ah yes, this is the wrong version of the patchset.  I already gave that
feedback and H.J. posted an update.  My bad.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2014-01-21 Thread Catalin Marinas
On Fri, Dec 27, 2013 at 05:25:05PM +, H.J. Lu wrote:
> X32 adjtimex system call is the same as x86-64 adjtimex system call,
> which uses 64-bit integer for long in struct timex. But x32 long is
> 32 bit.  This patch replaces long in struct timex with __kernel_long_t
> if __BITS_PER_LONG == 64.
> 
> Signed-off-by: H.J. Lu 
> ---
>  include/uapi/linux/timex.h | 46 
> ++
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/include/uapi/linux/timex.h b/include/uapi/linux/timex.h
> index a7ea81f..98314e9 100644
> --- a/include/uapi/linux/timex.h
> +++ b/include/uapi/linux/timex.h
> @@ -63,28 +63,58 @@
>   */
>  struct timex {
>   unsigned int modes; /* mode selector */
> +#if __BITS_PER_LONG == 64
> + __kernel_long_t offset; /* time offset (usec) */
> + __kernel_long_t freq;   /* frequency offset (scaled ppm) */
> + __kernel_long_t maxerror;/* maximum error (usec) */
> + __kernel_long_t esterror;/* estimated error (usec) */
> +#else
>   long offset;/* time offset (usec) */
>   long freq;  /* frequency offset (scaled ppm) */
>   long maxerror;  /* maximum error (usec) */
>   long esterror;  /* estimated error (usec) */
> +#endif

These changes should work on arm64 ILP32 as well.

>   int status; /* clock command/status */
> +#if __BITS_PER_LONG == 64
> + __kernel_long_t constant;/* pll time constant */
> + __kernel_long_t precision;/* clock precision (usec) (read only) */
> + __kernel_long_t tolerance;/* clock frequency tolerance (ppm)
> +* (read only)
> +*/
> +#else
>   long constant;  /* pll time constant */
>   long precision; /* clock precision (usec) (read only) */
>   long tolerance; /* clock frequency tolerance (ppm)
>* (read only)
>*/
> +#endif
>   struct timeval time;/* (read only, except for ADJ_SETOFFSET) */

struct timeval is already defined in terms of __kernel_long_t, so no
issues here either.

BTW, could we not avoid the #if and always use __kernel_long_t? This
wouldn't break the user ABI.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2014-01-21 Thread Catalin Marinas
On Fri, Dec 27, 2013 at 05:25:05PM +, H.J. Lu wrote:
 X32 adjtimex system call is the same as x86-64 adjtimex system call,
 which uses 64-bit integer for long in struct timex. But x32 long is
 32 bit.  This patch replaces long in struct timex with __kernel_long_t
 if __BITS_PER_LONG == 64.
 
 Signed-off-by: H.J. Lu hjl.to...@gmail.com
 ---
  include/uapi/linux/timex.h | 46 
 ++
  1 file changed, 38 insertions(+), 8 deletions(-)
 
 diff --git a/include/uapi/linux/timex.h b/include/uapi/linux/timex.h
 index a7ea81f..98314e9 100644
 --- a/include/uapi/linux/timex.h
 +++ b/include/uapi/linux/timex.h
 @@ -63,28 +63,58 @@
   */
  struct timex {
   unsigned int modes; /* mode selector */
 +#if __BITS_PER_LONG == 64
 + __kernel_long_t offset; /* time offset (usec) */
 + __kernel_long_t freq;   /* frequency offset (scaled ppm) */
 + __kernel_long_t maxerror;/* maximum error (usec) */
 + __kernel_long_t esterror;/* estimated error (usec) */
 +#else
   long offset;/* time offset (usec) */
   long freq;  /* frequency offset (scaled ppm) */
   long maxerror;  /* maximum error (usec) */
   long esterror;  /* estimated error (usec) */
 +#endif

These changes should work on arm64 ILP32 as well.

   int status; /* clock command/status */
 +#if __BITS_PER_LONG == 64
 + __kernel_long_t constant;/* pll time constant */
 + __kernel_long_t precision;/* clock precision (usec) (read only) */
 + __kernel_long_t tolerance;/* clock frequency tolerance (ppm)
 +* (read only)
 +*/
 +#else
   long constant;  /* pll time constant */
   long precision; /* clock precision (usec) (read only) */
   long tolerance; /* clock frequency tolerance (ppm)
* (read only)
*/
 +#endif
   struct timeval time;/* (read only, except for ADJ_SETOFFSET) */

struct timeval is already defined in terms of __kernel_long_t, so no
issues here either.

BTW, could we not avoid the #if and always use __kernel_long_t? This
wouldn't break the user ABI.

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2014-01-21 Thread H. Peter Anvin
On 01/21/2014 08:58 AM, Catalin Marinas wrote:
 
 BTW, could we not avoid the #if and always use __kernel_long_t? This
 wouldn't break the user ABI.
 

Ah yes, this is the wrong version of the patchset.  I already gave that
feedback and H.J. posted an update.  My bad.

-hpa

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2014-01-21 Thread Catalin Marinas
On Tue, Jan 21, 2014 at 05:03:09PM +, H. Peter Anvin wrote:
 On 01/21/2014 08:58 AM, Catalin Marinas wrote:
  BTW, could we not avoid the #if and always use __kernel_long_t? This
  wouldn't break the user ABI.
 
 Ah yes, this is the wrong version of the patchset.  I already gave that
 feedback and H.J. posted an update.  My bad.

Ah, I have to dig a newer version then.

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2013-12-27 Thread H. Peter Anvin
On 12/27/2013 09:25 AM, H.J. Lu wrote:
> X32 adjtimex system call is the same as x86-64 adjtimex system call,
> which uses 64-bit integer for long in struct timex. But x32 long is
> 32 bit.  This patch replaces long in struct timex with __kernel_long_t
> if __BITS_PER_LONG == 64.
> 
> Signed-off-by: H.J. Lu 
> ---
>  include/uapi/linux/timex.h | 46 
> ++
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/include/uapi/linux/timex.h b/include/uapi/linux/timex.h
> index a7ea81f..98314e9 100644
> --- a/include/uapi/linux/timex.h
> +++ b/include/uapi/linux/timex.h
> @@ -63,28 +63,58 @@
>   */
>  struct timex {
>   unsigned int modes; /* mode selector */
> +#if __BITS_PER_LONG == 64
> + __kernel_long_t offset; /* time offset (usec) */
> + __kernel_long_t freq;   /* frequency offset (scaled ppm) */
> + __kernel_long_t maxerror;/* maximum error (usec) */
> + __kernel_long_t esterror;/* estimated error (usec) */
> +#else
>   long offset;/* time offset (usec) */
>   long freq;  /* frequency offset (scaled ppm) */
>   long maxerror;  /* maximum error (usec) */
>   long esterror;  /* estimated error (usec) */
> +#endif
>   int status; /* clock command/status */

I thought we already discussed this?  No __BITS_PER_LONG conditionals,
please, unless you can strongly motivate them... and if so, we probably
should introduce another __kernel type instead.

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/8] Use __kernel_long_t in struct timex

2013-12-27 Thread H. Peter Anvin
On 12/27/2013 09:25 AM, H.J. Lu wrote:
 X32 adjtimex system call is the same as x86-64 adjtimex system call,
 which uses 64-bit integer for long in struct timex. But x32 long is
 32 bit.  This patch replaces long in struct timex with __kernel_long_t
 if __BITS_PER_LONG == 64.
 
 Signed-off-by: H.J. Lu hjl.to...@gmail.com
 ---
  include/uapi/linux/timex.h | 46 
 ++
  1 file changed, 38 insertions(+), 8 deletions(-)
 
 diff --git a/include/uapi/linux/timex.h b/include/uapi/linux/timex.h
 index a7ea81f..98314e9 100644
 --- a/include/uapi/linux/timex.h
 +++ b/include/uapi/linux/timex.h
 @@ -63,28 +63,58 @@
   */
  struct timex {
   unsigned int modes; /* mode selector */
 +#if __BITS_PER_LONG == 64
 + __kernel_long_t offset; /* time offset (usec) */
 + __kernel_long_t freq;   /* frequency offset (scaled ppm) */
 + __kernel_long_t maxerror;/* maximum error (usec) */
 + __kernel_long_t esterror;/* estimated error (usec) */
 +#else
   long offset;/* time offset (usec) */
   long freq;  /* frequency offset (scaled ppm) */
   long maxerror;  /* maximum error (usec) */
   long esterror;  /* estimated error (usec) */
 +#endif
   int status; /* clock command/status */

I thought we already discussed this?  No __BITS_PER_LONG conditionals,
please, unless you can strongly motivate them... and if so, we probably
should introduce another __kernel type instead.

-hpa


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/