Messages in this thread | | | Date | Thu, 22 Oct 1998 23:10:58 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft] |
| |
On Fri, 23 Oct 1998, Richard Gooch wrote: > Linus Torvalds writes: > > > > 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()". > > What system call is this? The i386 unistd.h makes no mention of it.
Sorry. I should have checked. The system call name is "times()", and it's one of the very few system calls that return time in "clock ticks" instead of the much saner and generic "struct timeval" that gives the time in a timer-independent format.
Anyway, the point being that you only need to make sure that "times()" (and any other system call I've forgotten about that has the same interface - search for "clock_t" to see - that's why I had the name confused) always returns its values as if the clock was running at 100 Hz. And the kernel internally can use a variable clock-rate for all we care.
The thing is, user programs really should not need to worry about kernel internal issues. The kernel should do the conversion for them (as it happens, the current "conversion" is a 1:1 thing, and as such the kernel doesn't need to do anything. But if Albert wants to have his clock tick at a kilohertz, he only needs to add a few "/10" to his kernel and he'll be all set).
A kernel that exports internal knowledge is a BAD kernel. And I will continue to refuse to make bad decisions like a sysctl() interface to HZ.
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/
| |