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/