This is not really true. There are new columns or lines added to /proc
files, but old ones are not changes, and correctly writen /proc parsers
should not break (unfortunately there are lots of incorrectly writen
proc parser around..)
>
> >>
> >> > 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...
First the kernel needs to export the necessary information. glibc is
hardly to blame here.
>
> > 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 ?
It has nothing to do with glibc. There are documented sysctls that use
HZ as unit, and Linux has long ago left the innocent state where you
can change documented interfaces without thinking and some migration
strategy.
-Andi
-- This is like TV. I don't like TV.- 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/