Linus Torvalds writes:
> On Fri, 28 Jul 2000, Albert D. Cahalan wrote:
>> So, officially, does this mean:
>>
>> 1. anybody needing greater resolution in /proc can go screw themselves
>> 2. anybody wanting a fast HZ without hacking /proc can do likewise
>> 3. anybody needing more than 32 groups can do likewise
>> 4. app and libc developers should not try to help these people
>
> Anybody who tries to create "sysconf()" to fix this can go screw
> themselves.
Well, that isn't what I asked about. We have another problem too.
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.
>> That won't handle dynamic stuff, like the number of online processors.
>> Make it /dev/sysconf and the problems go away.
>
> 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.
> How do you avoid stupid bloat?
>
> How does the kernel know that the sysconfig values for "expr" and
> "bc" etc should be? The kernel should not. The ADMINISTRATOR should!
Not every sysconf value need come from the same place. Values should
come from the kernel if and only if they are determined by the kernel.
This is easy enough, perhaps 0xa000 to 0xafff are reserved for
kernel values, with other ranges for libc and other junk.
> And it _does_ handle dynamic stuff. Go back and read the message. The
> administrator can _write_ to the file,
...
> the administrator can maintain it and do the
> right thing for _all_ of the system, not just the kernel-related values.
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.
-
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:30 EST