AK> This is not really true. There are new columns or lines added to /proc
AK> files, but old ones are not changes, and correctly writen /proc parsers
AK> should not break (unfortunately there are lots of incorrectly writen
AK> proc parser around..)
I yet to see "correct parser" with ability to find out file-max, file-nr,
inode-max and inode0-nr moved from /proc/sys/kernel in 2.0 to
/proc/sys/fs in 2.2...
>> >> > It is easy to add a read-only sysctl for HZ though and make netstat use
>> >> > this, but this won't fix the trillions of other /proc parsers.
>> >>
>> >> we do not want to export HZ, why should we? HZ has no meaning to anything
>> >> else than the kernel. If the kernel exports HZ-dependent values into
>> >> /proc, then that has to be fixed. (yes it might be painful in some cases)
>> >> HZ might even go away in future kernels - what if we start using
>> >> nonperiodic timer interrupts?
>>
>> > Actually, POSIX wants it (sysconf(_SC_CLK_TCK)). glibc currently returns
>> > the HZ value it was compiled with, but that is hardly satisfying.
>>
>> This means that GLiBC must be fixed...
AK> First the kernel needs to export the necessary information. glibc is
AK> hardly to blame here.
Of course. It's two step procedure :-) I do not blame GLibC here, I describe
what must be done...
>> > I agree that the time related sysctls/proc files should be fixed, but I'm
>> > afraid it is too late.
>>
>> /proc files are not a problem but sysctls... In which sysctls HZ is used in
>> such way that GLibC recompilation will not help ?
AK> It has nothing to do with glibc. There are documented sysctls that use
AK> HZ as unit, and Linux has long ago left the innocent state where you
AK> can change documented interfaces without thinking and some migration
AK> strategy.
When it "left the innocent state" ??? I always was sure that there are is
well-defined migration strategy: broke things in experimental branch and
make sure all needed programs will be updated...
Concerning HZ: what are those sysctls ? How many programs use them ?
-
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/