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.
> > Oh. And how do you handle 2.2.x kernels that don't have it?
>
> Fall back to the existing hacks as needed, then drop support
> for 2.2.x after 3.0.x is out.
And you do not see what is wrong with this?
Have you learned nothing at all from DOS and Windows?
Have you no _taste_?
And do you not realize that features never get dropped: they just end up
increasing the binary size and icache pressure forever?
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.
Your previous argument was CPU hotplug. I told you then that you could
just have simple administration tools to update the /etc/sysconf file.
What is it about this that you refuse to understand?
With /etc/sysconf all of the problems just magically go away.
> This is a maintenance horror for millions of clueless sysadmins.
> Going with binary makes the horror worse, while going with text
> will help slow down every Linux executable using glibc.
The binary file is generated pretty much _once_. At glibc installation
time. Make it automatic when you install the glibc rpm. The same way that
"ldconfig" is run automatically. What's so hard to administer?
Once your adminstrator starts hot-swapping CPU's and memory etc, he can
just re-run the generation tool. Or use perl scripts or whatever to do it
especially. Trust me, when you do hot-plug anything, you need to
administer it. It doesn't have to be hard.
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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:31 EST