H. Peter Anvin writes:
> [Theodore Y. Ts'o writes]
>> Linus is right, no major structural change is necessary. For example,
>> here's a very short patch necessary to support __SC_CLK_TCK (which is
>> probably the most interesting of the sysconf() variables as far as I'm
>> concerned.) It's only a 5-line patch. (See below)
>
> I don't think we want to do this! IMO, HZ should not get exported to
> user space *AT ALL*. Instead, for the few interfaces that need it,
> we'll export a "user space HZ" (USER_HZ) which is fixed. No need for
> a kernel hack. When we support nonstandard values for HZ, we need to
> fix the few interfaces that actually export jiffies values to convert
> from "user jiffies" to real jiffies.
We should export the "user jiffies". Eventually this _may_ become a
real per-arch constant, but for now it is not. For now it is just HZ,
and you can't stop people from adjusting it. User-space already has
to hack around the lack of __SC_CLK_TCK, and I assure you that it is
very gross... the procps code could make you vomit.
The only promise needed is that __SC_CLK_TCK match the units used
in /proc and tick-based system call(s). Even if HZ were to die, we'd
still need some sort of unit to represent stuff in /proc. That unit
is the one that userspace needs.
Suggestion for glibc NGROUPS_MAX problem: in the typical way of
hacking around lack of kernel support, have glibc run a setuid-root
executable that reads kernel memory. Use the System.map file to
seek out a suitable spot. You get bonus points for using statistical
methods or arch-specific disassembly of the executable code.
-
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:26 EST