lkml.org 
[lkml]   [2000]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.127 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site