Rogier Wolff wrote:
> H. Peter Anvin wrote:
> > > Due to machines that can't program their clocks to the standard clock rate
> > > I've created a patch which does things somewhat different. I found the
> > > USER_HZ approach to be insufficient, there is a lot of software out there
> > > which uses <linux/param.h>'s HZ definition directly upto and including the
> > > current glibc development snapshot, so you're more or less forced to live
> > > with HZ.
> > >
> >
> > #define USER_HZ 100
> >
> > #ifdef __KERNEL__
> > #define HZ 1024
> > #else
> > #define HZ USER_HZ
> > #endif
>
> Just a coding style change:
>
>
> #ifdef __KERNEL__
> #define HZ CONFIG_HZ
> #else
> /* Exported API has HZ equal to 100. This is a constant, and not going to
> change the next millennium. */
> #define HZ 100
> #endif
>
> Note that a Certain mr. Linus B. Torvalds is going to prefer:
>
> #define HZ CONFIG_HZ
>
> without the #ifdef around it.
>
You still need to have the USER_HZ constant in kernel space, since it
differs between architectures (it's 1024, for example, on Alpha.) Thus:
#define USER_HZ 100 /* Architecture dependent */
#ifdef __KERNEL__
#define HZ CONFIG_HZ /* What the kernel uses */
#else
#define HZ USER_HZ /* What user space sees */
#endif
Another alternative is to simply get rid of all uses of HZ in the
kernel, and replace it with either CONFIG_HZ or USER_HZ. This has the
additional benefit of giving a compiler error when not used properly. Thus:
#define USER_HZ 100 /* Arch dependent */
#ifndef __KERNEL__
#define HZ USER_HZ
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:32 EST