On Sat, Jul 08, 2006 at 07:07:14AM -0600, David Mosberger-Tang wrote:
> Nothing is broken. Read Alan's statement carefully...
>
> --david
His statement can be read a couple of ways.
Let's go over the choices.
First, the background. Some apps are using the HZ definition in
/usr/include/asm/param.h to get the system's HZ value. That is a
bug in the app -- everyone agrees.
Currently, on IA64, HZ is defined to be 1024, which is incorrect
for newer kernels.
Options:
1. Change to 250, which will be correct for most distributions as
well as the default IA64 kernel
2. Leave at 1024, which is wrong for everything
3. Change to sysconf(_SC_CLK_TCK) so that apps get the right thing
4. Change to something that produces a build error to indicate to app
maintainer that he needs to fix something.
5. Change kernel to make it compatible with old apps that think
system HZ is 1024.
Currently, the option chosen is (3). It doesn't seem like the best
option to me -- maybe the worst, actually. I would like to see at
least one explanation as to why it's been chosen.
jeremy
> On 7/8/06, Arjan van de Ven <[email protected]> wrote:
> >
> >
> >> So does i386 convert the return value of the times(2) call to user
> >> hertz? On IA64, it returns the value in internal clock ticks, and
> >> then when a program uses the value in param.h, it gets it wrong now,
> >> because internal HZ is now 250.
> >>
> >> So is times() is broken in IA64, or is this an exception to Alan's
> >> statement?
> >
> >yes it's broken; it needs to convert it to the original HZ (1024) and
> >make the sysconf() function also return 1024
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
