I have no problem with just long. David Mosberger suggested the
"long long" because it would always be the longest integer type
and therefore overflow less often (if at all). But for now, you
are right.
New patch attached.
-- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/diff -ruN 2.5.52-32bit.base/include/linux/compat.h 2.5.52-32bit.clock/include/linux/compat.h --- 2.5.52-32bit.base/include/linux/compat.h 2002-12-16 14:49:54.000000000 +1100 +++ 2.5.52-32bit.clock/include/linux/compat.h 2002-12-17 15:20:18.000000000 +1100 @@ -9,9 +9,11 @@ #ifdef CONFIG_COMPAT #include <linux/stat.h> +#include <linux/param.h> /* for HZ */ #include <asm/compat.h> -#define compat_jiffies_to_clock_t(x) ((x) / (HZ / COMPAT_USER_HZ)) +#define compat_jiffies_to_clock_t(x) \ + (((unsigned long)(x) * COMPAT_USER_HZ) / HZ) struct compat_utimbuf { compat_time_t actime; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/