>> It's not a different value in libproc. There's autodetection.
>> I can't just support "the majority of ARM", and people keep
>> giving me shit about HZ supposedly being a per-arch constant.
>> (not that there's a sane way to get a per-arch constant from
>> user code anyway)
>
> But that's just _wrong_.
If you only support recent kernels and glibc, true.
Debian is about to release a distribution with the 2.2 kernel.
> There _is_ a sane way to get the per-arch constant, and there has been for
> a long long time.
Your "long long time" is very different, because you
always (?) run the very latest kernel.
> The kernel exports it with the AT_CLKTCK ELF auxiliary note to every ELF
> binary ever loaded, and I think glibc in turn exports that value through
> the regular sysconf(_SC_CLK_TCK) thing. (Yeah, I disagree with some of the
> glibc sysconf implementation, but it sure should be there, and it's
> documented).
>
> If that doesn't work, then it's a glibc bug (well, in theory there could
> be a kernel bug too, but since it's a one-liner in the kernel I really
> doubt it).
Yeah, NOW it should work fine. App code sees:
old glibc and old kernel --> guess
old glibc and new kernel --> guess
new glibc and old kernel --> guess
new glibc and new kernel --> useful data
(the guess is correct for unmodified x86)
Two problems with that:
1. must handle the "guess" case
2. can't tell a guess from useful data!
So I can't use the useful data for a few more years.
I can cut that time down to maybe 2 years if I write
code to dig up the ELF notes myself, assuming that
were introduced with the 2.4 kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/