Linus Torvalds writes:
> On Sat, 29 Jul 2000, Albert D. Cahalan wrote:
>> ARM systems can have HZ be either 100 or 64, because some hardware
>> does not support 100. MIPS, Alpha, and ia64 all seem to support more
>> than one HZ value. According to you, binaries should not depend on
>> what platform they were compiled for. Asking the admin to supply HZ
>> is silly when the kernel damn well knows what it is. So there is no
>> sane way to even create this "/etc/sysconf" file you propose.
>
> No.
>
> You're asking the wrong question.
>
> There is no sane reason for the OS to expose HZ. We did it for historical
> reasons, because it is the easy thing to do. But you have to understand
> what the primary objective of an OS is: to create a virtual environment
> that is simple and sane to program against.
>
> The fact that you think you need sysconf() means that the OS is not doing
> a good job!
>
> And that is one of the fundamental arguments against a sysconf() system
> call. It is an implicit admission that there is something wrong, and
> instead of fixing it you expose some interface that gives whatever random
> fixed numbers the kernel was compiled with.
OK, great. Are you ready to fix it? There are existing patches that
you have not applied. (they convert for /proc display) Want them now?
This isn't without faults of course. It puts the conversion code
in kernel space. That is more kernel bloat that a mere sysconf().
There is also a loss of accuracy due to round-off or truncation,
instead of /proc becoming more accurate as HZ is increased.
> And do you not realize that features never get dropped: they just
> end up increasing the binary size and icache pressure forever?
Nah, I dropped support for Linux 1.2 and 2.0 already.
Nobody even noticed.
> I have yet to hear a _single_ argument that invalidates the "mmap
> /proc/sysconf" approach. Your HZ argument does _not_ do it. It's very easy
> indeed for an install-script to determine what kind of machine it runs on,
> and then write the appropriate value to /etc/sysconf. This is not rocket
> science.
Ugh, grepping the boot messages.
-
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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:32 EST