Messages in this thread | | | Date | Fri, 23 Oct 1998 08:22:23 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft] |
| |
On 23 Oct 1998, Andi Kleen wrote: > > > 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. > > It already happened: most of the /proc/sys/net/ipv4/route* sysctls are in > jiffies.
A perfect example of something completely and utterly stupid.
But "two stupids do not make a clever". Current stupidity is no excuse for adding more of it.
So instead of people sending me patches to export HZ to increase our level of incompetence, how about people send me patches to fix these things instead?
Notice that stuff like /proc is _expecially_ not soemthing that wouldn't get helped by the user knowing about HZ. Because /proc can be used from other machines. Some MIS person is _supposed_ to be able to do something like
rsh xxx "echo 1 > /proc/sys/xxx/xxxx"
without having to worry about whether "1" is in increments of .01 s or some other random interface.
In short, this is about interface design.
And happily, we can _fix_ our interfaces instead of just screwing up even more.
> For soft RT apps it makes sense to recompile the kernel with a higher HZ, > and it would be nice if it wasn't required to recompile glibc too @)
Andi, you normally understand things. Repeat after me:
"Increasing the kernel HZ is not an excuse for changing a documented interface to user space. You can make the kernel clock tick at a gigahertz, but that doesn't mean that the user program needs or wants to know."
How many times do I need to say this?
When I change how the page cache works, do I suddenly change the "read()" system call to take different parameters? No. Similarly, any user should not be aware of what the kernel does internally to keep its timers up-to-date. It's supposed to be opaque.
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/
| |