Messages in this thread | | | Date | Fri, 28 Jul 2000 00:09:41 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: sysconf (was Re: RLIM_INFINITY inconsistency between archs) |
| |
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/
| |