Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft]

Linus Torvalds (torvalds@transmeta.com)
Thu, 22 Oct 1998 22:07:28 -0700 (PDT)


On Fri, 23 Oct 1998, Albert D. Cahalan wrote:
>
> > HZ is already there. It's defined to be 100. You get it from
> > the header files. End of story.
>
> So we are stuck with 100 until the end of time? That just sucks.

Albert. Take a deep breath, and then USE YOUR BRAIN for a second.

It really helps. And I've been continually disgusted by how _little_
people use their brain, especially when it comes to glibc issues.

There is ABSOLUTELY no point in having a variable HZ interface to user
mode. None. Nada. Zilch.

Especially as the only thing that knows about HZ is "clock_t", and if I
remember correctly the _only_ system call that actually returns a clock_t
is "clock()".

If you want to make the kernel internally use a different clock frequency
than 100 HZ, then feel free to do so. But if your changed kernel shows
that internal change in the return value of clock(), then your changed
kernel is broken.

Quite frankly, these days I completely ignore all patches that come from
the glibc guys, exactly because they so very obviously have never given a
nanoseconds worth of thought to whether it makes any sense at all to make
something variable or not.

In short: HZ is not variable. Neither is the coprocessor reset value.

What you are suggesting is akin to making a sysconfig entry for the value
of PI. You can do it, but there is no point.

Linus

-
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/