> The fact that libproc believes that HZ can change is _their_ problem.
> I've told people over and over that user-level HZ is a constant (and, on
> x86, that constant is 100), and that won't change.
Was HZ supposed to be 1024 or 1200 on alpha?
How about arm... 64, 128, or 1000?
Not even counting user-mode-linux at 20 HZ, there were
about _five_ archs in your official kernel source that
indirectly made HZ a config option.
> So in current 2.5.x times() still counts at 100Hz, and /proc files that
> export clock_t still show the same 100Hz rate.
Good. That works for the 2.5 kernel and above, assuming you
did something about alpha, arm, ia64, s390, and mips.
Unfortunately, the hack must remain for another 4 years or so.
Maybe that's not so bad though. I prefer it over this:
#ifdef __386__
#define HZ 100
#endif
#ifdef __IA64__
#define HZ 1024
#endif
#ifdef __ARM__
#define HZ 128 // if they settle on this
#endif
#ifdef __S390__
#define HZ 10
#endif
...
-
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/