[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.177 / U:1.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site