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 <arjan@xxxxxxxxxxxxx> 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 - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |