>>> HZ is already there. It's defined to be 100. You get it from
>>> the header files. End of story.
>>
>> So we are stuck with 100 until the end of time? That just sucks.
>
> Albert. Take a deep breath, and then USE YOUR BRAIN for a second.
Do you plan to keep HZ==100 on Intel forever? Would that even include
64-bit chips? Note that people will want to run 32-bit Linux software
on 64-bit hardware. Unless you really want to keep that crappy value,
you need a transition plan.
> It really helps. And I've been continually disgusted by how _little_
> people use their brain, especially when it comes to glibc issues.
This isn't a glibc issue. I'd be happy to bypass glibc to get
access to such information.
> There is ABSOLUTELY no point in having a variable HZ interface to user
> mode. None. Nada. Zilch.
>
> Especially as the only thing that knows about HZ is "clock_t", and if I
> remember correctly the _only_ system call that actually returns a clock_t
> is "clock()".
There is a sys_times(), which can become sys_oldtimes() if needed.
There are far worse problems in /proc. Jiffies are directly reported
all over /proc.
> If you want to make the kernel internally use a different clock frequency
> than 100 HZ, then feel free to do so. But if your changed kernel shows
> that internal change in the return value of clock(), then your changed
> kernel is broken.
Agreed, at least in terms of system call number.
> Quite frankly, these days I completely ignore all patches that come from
> the glibc guys, exactly because they so very obviously have never given a
> nanoseconds worth of thought to whether it makes any sense at all to make
> something variable or not.
I need this for a non-glibc purpose.
> In short: HZ is not variable. Neither is the coprocessor reset value.
Whoa, STOP! The coprocessor reset value is part of the Linux personality
on 32-bit Intel hardare. It would be easy to have a new personality
with a new coprocessor reset value; old software would still work.
The data in /proc is shared by all processes. It is much harder to
support old software reading /proc.
> What you are suggesting is akin to making a sysconfig entry for the value
> of PI. You can do it, but there is no point.
Gee. Someday I will get a 5000-MHz CPU running the scheduler at 100 HZ.
My 30 Gb/s fiber optic serial ports will work great, eh? Pardon me
while I puke.
We CAN NOT CHANGE without a transition plan.
It is very hard to change HZ without breaking stuff. That is why it
would be very good to provide support _years_ in advance.
-
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/