[lkml]   [2000]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: sysconf (was Re: RLIM_INFINITY inconsistency between archs)
    Ralf Baechle wrote:
    > On Thu, Jul 27, 2000 at 05:34:54PM -0700, H. Peter Anvin wrote:
    > > > 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.
    > Due to machines that can't program their clocks to the standard clock rate
    > I've created a patch which does things somewhat different. I found the
    > USER_HZ approach to be insufficient, there is a lot of software out there
    > which uses <linux/param.h>'s HZ definition directly upto and including the
    > current glibc development snapshot, so you're more or less forced to live
    > with HZ.

    #define USER_HZ 100

    #ifdef __KERNEL__
    #define HZ 1024
    #define HZ USER_HZ

    <> at work, <> in private!
    "Unix gives you enough rope to shoot yourself in the foot."

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.041 / U:21.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site