I need to know the kernels value of HZ in a userland app.
getconf CLK_TCK
and
hz = sysconf (_SC_CLK_TCK)
both seem to return CLOCKS_PER_SEC which is defined as USER_HZ which is
defined as 100.
include/asm/param.h:
#ifdef __KERNEL__
# define HZ 1000 /* Internal kernel timer frequency */
# define USER_HZ 100 /* .. some user interfaces are in "ticks" */
# define CLOCKS_PER_SEC (USER_HZ) /* like times() */
#endif
Thanks in advance for any help
Mark
On Tue, 13 Sep 2005, Mark Hounschell wrote:
> I need to know the kernels value of HZ in a userland app.
>
> getconf CLK_TCK
> and
> hz = sysconf (_SC_CLK_TCK)
>
> both seem to return CLOCKS_PER_SEC which is defined as USER_HZ which is
> defined as 100.
>
> include/asm/param.h:
>
> #ifdef __KERNEL__
> # define HZ 1000 /* Internal kernel timer frequency */
> # define USER_HZ 100 /* .. some user interfaces are in "ticks" */
> # define CLOCKS_PER_SEC (USER_HZ) /* like times() */
> #endif
>
> Thanks in advance for any help
> Mark
You are not supposed to 'tear apart' user-mode headers. In particular
you are not supposed to use anything in /usr/include/bits, /usr/include/asm,
or /usr/include/linux in user-mode programs. These are not POSIX headers.
Therefore, HZ is not something that is defined for user-mode programs.
the ANSI spec requires that things like clock() return a value that
can be divided by CLOCKS_PER_SEC to get CPU time. Nothing in user-mode
uses HZ. That's the reason why later versions of the kernel are
able to use dynamic HZ.
You will not find HZ in /usr/include/time.h or /usr/include/sys/time.h
because it's not supposed to be there, but these headers may reference
something that you are not supposed to look at in your programs.
If a user-mode program needs to know HZ, it is very, very, broken.
HZ is some kernel timeout tick which doesn't relate to anything
a user program needs to know.
If you are making a program that accesses /proc (therefore non-
standard and non portable), to obtain some kernel information,
some of which may be in HZ, you need to access the kernel headers
for the kernel that is running at the time that /proc is accessed.
This is a problem and is why we should have a kernel system-call
that returns the HZ value. I asked about this several years ago
and its inclusion was flatly refused because of what I quoted
above. Perhaps now that HZ are dynamic, it would be posasible to
add that system call.
Note, that on this particular kernel, at this phase of the moon...
This program returns the HZ value.
#include <stdio.h>
#include <unistd.h>
int main()
{
printf("%d\n", sysconf(_SC_CLK_TCK));
return 0;
}
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
linux-os (Dick Johnson) wrote:
> On Tue, 13 Sep 2005, Mark Hounschell wrote:
>
>>I need to know the kernels value of HZ in a userland app.
>>
>>getconf CLK_TCK
>> and
>>hz = sysconf (_SC_CLK_TCK)
>>
>>both seem to return CLOCKS_PER_SEC which is defined as USER_HZ which is
>>defined as 100.
>>
>>include/asm/param.h:
>>
>>#ifdef __KERNEL__
>># define HZ 1000 /* Internal kernel timer frequency */
>># define USER_HZ 100 /* .. some user interfaces are in "ticks" */
>># define CLOCKS_PER_SEC (USER_HZ) /* like times() */
>>#endif
>>
>>Thanks in advance for any help
>>Mark
>
> You are not supposed to 'tear apart' user-mode headers. In particular
> you are not supposed to use anything in /usr/include/bits, /usr/include/asm,
> or /usr/include/linux in user-mode programs. These are not POSIX headers.
>
This was a kernel header used for reference. I'm not including them.
> If a user-mode program needs to know HZ, it is very, very, broken.
> HZ is some kernel timeout tick which doesn't relate to anything
> a user program needs to know.
>
Most if not all userland delay calls rely on HZ value in some way or
another. The minimum reliable delay you can get is one (kernel)HZ. A
program that needs an acurrate delay for a time shorter that one
(kernel)HZ may have an alternative if it knows that HZ is greater the
the requested delay. So to say my program is broken because it wants to
know the limitations of my OS/kernel is kind of far fetched.
> This is a problem and is why we should have a kernel system-call
> that returns the HZ value. I asked about this several years ago
> and its inclusion was flatly refused because of what I quoted
> above. Perhaps now that HZ are dynamic, it would be posasible to
> add that system call.
>
I'll second that. I thought sysconf(_SC_CLK_TCK) was supposed to be that
call.
> Note, that on this particular kernel, at this phase of the moon...
> This program returns the HZ value.
>
> #include <stdio.h>
> #include <unistd.h>
>
> int main()
> {
> printf("%d\n", sysconf(_SC_CLK_TCK));
> return 0;
> }
>
>
>
No it does not. It returns USER_HZ. At least on any 2.6.12 and <.
Mark
On Tue, 13 Sep 2005, Mark Hounschell wrote:
> I need to know the kernels value of HZ in a userland app.
Why?
You are supposed _not_ to know it. If you think you need it, something's
wrong.
Tim
On Tue, 13 Sep 2005, Mark Hounschell wrote:
> Most if not all userland delay calls rely on HZ value in some way or
> another. The minimum reliable delay you can get is one (kernel)HZ. A
> program that needs an acurrate delay for a time shorter that one
> (kernel)HZ may have an alternative if it knows that HZ is greater the
> the requested delay.
Just assume that kernel HZ are USER_HZ and see anything else as an
additional bonus that you cannot rely on.
What does 'acurrate delay' mean, anyways?
Tim
Tim Schmielau wrote:
> On Tue, 13 Sep 2005, Mark Hounschell wrote:
>
>>Most if not all userland delay calls rely on HZ value in some way or
>>another. The minimum reliable delay you can get is one (kernel)HZ. A
>>program that needs an acurrate delay for a time shorter that one
>>(kernel)HZ may have an alternative if it knows that HZ is greater the
>>the requested delay.
>
> Just assume that kernel HZ are USER_HZ and see anything else as an
> additional bonus that you cannot rely on.
>
> What does 'acurrate delay' mean, anyways?
>
> Tim
>
But they are not the same. Why can I get USER_HZ but not HZ?
On a 100HZ kernel ANY requested delay via udelay or
pthread_cond_timedwait of less than 10000usecs is unreliable and the the
actual results are totally unacceptable.
On a 1000HZ kernel the number is 1000 usecs.
I'm not asking the kernel running at 1000hz to actually give me 500 usec
delay if I ask. I do expect it to be at least 500 usec and within +- a
single HZ however. Oviously a 1000HZ machine is going to give me better
resulution in any requested delay. Why is it unreasonable for userland
to know the probable resolution of userland delay requests.
For those required delays less than a HZ I have alternatives that are
more accruate than += one HZ. I just need to know the kernel HZ in order
to better predict when my alternative methods will be prefered.
Mark
On Tue, 13 Sep 2005, Mark Hounschell wrote:
> On a 100HZ kernel ANY requested delay via udelay or
> pthread_cond_timedwait of less than 10000usecs is unreliable and the the
> actual results are totally unacceptable.
>
> On a 1000HZ kernel the number is 1000 usecs.
>
> I'm not asking the kernel running at 1000hz to actually give me 500 usec
> delay if I ask. I do expect it to be at least 500 usec and within +- a
> single HZ however.
The kernel just cannot guarantee the latter. Rounding is only one of
many issues here.
Do you also want to know about CONFIG_PREEMPT, SMP, current load, future
load in order to estimate the delay you want to ask for?
OTOH, I'm not a soft real-time expert, so I'll stop commenting here.
Tim
Tim Schmielau wrote:
.
> Do you also want to know about CONFIG_PREEMPT, SMP, current load, future
> load in order to estimate the delay you want to ask for?
>
No. The delays I 'require' are not estimated. They are constant. What is
estimated is the kernels ability to give what I require. And that varies
greatly between a 100HZ kernel and a 1000HZ kernel.
So what is the returned valu of sysconf(_SC_CLK_TCK) good for?
Mark
Tim Schmielau wrote:
> Do you also want to know about CONFIG_PREEMPT, SMP, current load, future
> load in order to estimate the delay you want to ask for?
Are not CONFIG_PREEMPT, SMP, and current load, all determinable from
userland anyway? Why not HZ?
Mark
On Tue, 2005-09-13 at 11:05 -0400, Mark Hounschell wrote:
> Tim Schmielau wrote:
> > On Tue, 13 Sep 2005, Mark Hounschell wrote:
> >
> >>Most if not all userland delay calls rely on HZ value in some way or
> >>another. The minimum reliable delay you can get is one (kernel)HZ. A
> >>program that needs an acurrate delay for a time shorter that one
> >>(kernel)HZ may have an alternative if it knows that HZ is greater the
> >>the requested delay.
> >
> > Just assume that kernel HZ are USER_HZ and see anything else as an
> > additional bonus that you cannot rely on.
> >
> > What does 'acurrate delay' mean, anyways?
> >
> > Tim
> >
>
> But they are not the same. Why can I get USER_HZ but not HZ?
Because USER_HZ is there only because HZ changes on various systems and
we don't want to break userland apps that assume its value.
> On a 100HZ kernel ANY requested delay via udelay or
> pthread_cond_timedwait of less than 10000usecs is unreliable and the the
> actual results are totally unacceptable.
>
> On a 1000HZ kernel the number is 1000 usecs.
>
> I'm not asking the kernel running at 1000hz to actually give me 500 usec
> delay if I ask. I do expect it to be at least 500 usec and within +- a
> single HZ however. Oviously a 1000HZ machine is going to give me better
> resulution in any requested delay. Why is it unreasonable for userland
> to know the probable resolution of userland delay requests.
But you don't really want to know HZ, you want to know timer resolution.
That's a reasonable request and I believe the posix-timers
clock_getres() interface might provide what you need. Although I'd defer
to George (CC'ed) since he's more of an expert on those interfaces.
You might also want to check out his HRT patches.
thanks
-john
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Hounschell wrote:
> Tim Schmielau wrote:
>
>> Do you also want to know about CONFIG_PREEMPT, SMP, current load, future
>> load in order to estimate the delay you want to ask for?
>
>
> Are not CONFIG_PREEMPT, SMP, and current load, all determinable from
> userland anyway? Why not HZ?
And with dynamic HZ?
Do you want
a) The HZ that was used when we booted
b) The HZ that is currently used (say 22, but could be 573 in 0.1s)
c) The MIN HZ (if there is such a thing and it is configured)
that the kernel will use.
d) The MAX HZ (same) that the kernel will use.
Or do you want USER_HZ?
Or are you after something else entirely.
// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDJxyjBrn2kJu9P78RAmgUAKCAhcOexz9zGIY8PLrqL4v/m+s9fgCgh/Q/
4yQ0qwPqHp9AbV2qHC8Mgs8=
=uCFK
-----END PGP SIGNATURE-----
john stultz wrote:
>
> But you don't really want to know HZ, you want to know timer resolution.
> That's a reasonable request and I believe the posix-timers
> clock_getres() interface might provide what you need. Although I'd defer
> to George (CC'ed) since he's more of an expert on those interfaces.
>
> You might also want to check out his HRT patches.
>
> thanks
> -john
Thanks John that does in fact seem to do what I needed. It gives me
enough info that I can tell the HZ of the running kernel. HaHa...
I'm familiar with the HRT stuff as it was on the 2.4 kernel.
Thanks
Mark
Stefan Smietanowski wrote:
> Mark Hounschell wrote:
>>>Tim Schmielau wrote:
>>>
>>>>Do you also want to know about CONFIG_PREEMPT, SMP, current load, future
>>>>load in order to estimate the delay you want to ask for?
>>>
>>>Are not CONFIG_PREEMPT, SMP, and current load, all determinable from
>>>userland anyway? Why not HZ?
>
> And with dynamic HZ?
>
> Do you want
> a) The HZ that was used when we booted
> b) The HZ that is currently used (say 22, but could be 573 in 0.1s)
> c) The MIN HZ (if there is such a thing and it is configured)
> that the kernel will use.
> d) The MAX HZ (same) that the kernel will use.
>
> Or do you want USER_HZ?
>
> Or are you after something else entirely.
>
> // Stefan
If dynamic HZ means dynamic timer resolutions I don't want it at all.
I guess the 'terms' John just used, ie timer resolutions, as opposed to
HZ was maybe what I really should have asked for to begin with.
However since they are both bascially the same or at least one derived
from the other......?
Thanks
Mark
From: "linux-os (Dick Johnson)" <[email protected]>
>
> On Tue, 13 Sep 2005, Mark Hounschell wrote:
>
>> I need to know the kernels value of HZ in a userland app.
>>
>> getconf CLK_TCK
>> and
>> hz = sysconf (_SC_CLK_TCK)
>>
>> both seem to return CLOCKS_PER_SEC which is defined as USER_HZ which is
>> defined as 100.
>>
>> include/asm/param.h:
>>
>> #ifdef __KERNEL__
>> # define HZ 1000 /* Internal kernel timer frequency */
>> # define USER_HZ 100 /* .. some user interfaces are in "ticks" */
>> # define CLOCKS_PER_SEC (USER_HZ) /* like times() */
>> #endif
>>
>> Thanks in advance for any help
>> Mark
>
> You are not supposed to 'tear apart' user-mode headers. In particular
> you are not supposed to use anything in /usr/include/bits,
> /usr/include/asm,
> or /usr/include/linux in user-mode programs. These are not POSIX headers.
>
> Therefore, HZ is not something that is defined for user-mode programs.
> the ANSI spec requires that things like clock() return a value that
> can be divided by CLOCKS_PER_SEC to get CPU time. Nothing in user-mode
> uses HZ. That's the reason why later versions of the kernel are
> able to use dynamic HZ.
That means Linux is not a suitable operating system for multimedia
applications.
MIDI needs to schedule in 1 ms or smaller increments. The userland
application
should be able to set this. It should be able to determine this. If it
cannot
then it is useless. (It also explains why MIDI based applications are so
absolutely dreadful on Linux.)
{^_^} Joanne Dow said that.
On Tue, 13 Sep 2005, jdow wrote:
> From: "linux-os (Dick Johnson)" <[email protected]>
>>
>> On Tue, 13 Sep 2005, Mark Hounschell wrote:
>>
>>> I need to know the kernels value of HZ in a userland app.
>>>
>>> getconf CLK_TCK
>>> and
>>> hz = sysconf (_SC_CLK_TCK)
>>>
>>> both seem to return CLOCKS_PER_SEC which is defined as USER_HZ which is
>>> defined as 100.
>>>
>>> include/asm/param.h:
>>>
>>> #ifdef __KERNEL__
>>> # define HZ 1000 /* Internal kernel timer frequency */
>>> # define USER_HZ 100 /* .. some user interfaces are in "ticks" */
>>> # define CLOCKS_PER_SEC (USER_HZ) /* like times() */
>>> #endif
>>>
>>> Thanks in advance for any help
>>> Mark
>>
>> You are not supposed to 'tear apart' user-mode headers. In particular
>> you are not supposed to use anything in /usr/include/bits,
>> /usr/include/asm,
>> or /usr/include/linux in user-mode programs. These are not POSIX headers.
>>
>> Therefore, HZ is not something that is defined for user-mode programs.
>> the ANSI spec requires that things like clock() return a value that
>> can be divided by CLOCKS_PER_SEC to get CPU time. Nothing in user-mode
>> uses HZ. That's the reason why later versions of the kernel are
>> able to use dynamic HZ.
>
> That means Linux is not a suitable operating system for multimedia
> applications.
> MIDI needs to schedule in 1 ms or smaller increments. The userland
> application
> should be able to set this. It should be able to determine this. If it
> cannot
> then it is useless. (It also explains why MIDI based applications are so
> absolutely dreadful on Linux.)
>
> {^_^} Joanne Dow said that.
>
>
Well no. MIDI stuff has drivers that interface with precision timers
in your audio board such as Creative Labs Soundblaster. They have
a serial connection that, with a simple adapter becomes MIDI I/O.
These boards, and even the ones built into motherboards can (do)
generate and receive precision MIDI.
Although I use Cakewalk Home Studio for my MIDI stuff, there is
similar software and drivers for Linux. Search on "MIDI Linux".
In any event, the MIDI stuff could care less about the usual user-
mode timers. That's now how MIDI works. If you intend to make some
MIDI stuff in user-mode, not using hardware timing, your code is
broken from the start. Note that M$ has worse timer resolution
than Linux and the Cakewalk stuff is superb.
If there are MIDI programs that are, as you say, dreadful on
linux, then it's because the programs suck, not because of any
kernel timers.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, 13 Sep 2005, Mark Hounschell wrote:
> Stefan Smietanowski wrote:
> > Mark Hounschell wrote:
> > > >Tim Schmielau wrote:
> > > >
> > > > >Do you also want to know about CONFIG_PREEMPT, SMP, current load,
> > > > >future
> > > > >load in order to estimate the delay you want to ask for?
> > > >
> > > >Are not CONFIG_PREEMPT, SMP, and current load, all determinable from
> > > >userland anyway? Why not HZ?
> >
> > And with dynamic HZ?
> >
> > Do you want
> > a) The HZ that was used when we booted
> > b) The HZ that is currently used (say 22, but could be 573 in 0.1s)
> > c) The MIN HZ (if there is such a thing and it is configured)
> > that the kernel will use.
> > d) The MAX HZ (same) that the kernel will use.
> >
> > Or do you want USER_HZ?
> >
> > Or are you after something else entirely.
> >
> > // Stefan
>
> If dynamic HZ means dynamic timer resolutions I don't want it at all.
>
> I guess the 'terms' John just used, ie timer resolutions, as opposed to
> HZ was maybe what I really should have asked for to begin with.
>
> However since they are both bascially the same or at least one derived
> from the other......?
There's nothing to say that the kernel couldn't have hardware programmed
to give an interrupt and schedule your process at some point that wouldn't
normally be a scheduler tick. So the HRT interface could give you better
than HZ. Also, there's the possibility that the kernel could slack off on
HZ when you're not using HRT, and then there are patches for "tickless",
where it just programs the timer for the next time something is scheduled
to happen, and there's no fixed rate outside of actual activity.
-Daniel
*This .sig left intentionally blank*
On 9/13/05, Mark Hounschell <[email protected]> wrote:
> I need to know the kernels value of HZ in a userland app.
>
> getconf CLK_TCK
> and
> hz = sysconf (_SC_CLK_TCK)
>
> both seem to return CLOCKS_PER_SEC which is defined as USER_HZ which is
> defined as 100.
>
> include/asm/param.h:
>
> #ifdef __KERNEL__
> # define HZ 1000 /* Internal kernel timer frequency */
> # define USER_HZ 100 /* .. some user interfaces are in "ticks" */
> # define CLOCKS_PER_SEC (USER_HZ) /* like times() */
> #endif
>
> Thanks in advance for any help
> Mark
simply zgrep HZ= /proc/config.gz
on my box, I get CONFIG_HZ=1000
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
john stultz wrote:
> On Tue, 2005-09-13 at 11:05 -0400, Mark Hounschell wrote:
>
>>Tim Schmielau wrote:
>>
>>>On Tue, 13 Sep 2005, Mark Hounschell wrote:
>>>
>>>
>>>>Most if not all userland delay calls rely on HZ value in some way or
>>>>another. The minimum reliable delay you can get is one (kernel)HZ. A
>>>>program that needs an acurrate delay for a time shorter that one
>>>>(kernel)HZ may have an alternative if it knows that HZ is greater the
>>>>the requested delay.
>>>
>>>Just assume that kernel HZ are USER_HZ and see anything else as an
>>>additional bonus that you cannot rely on.
>>>
>>>What does 'acurrate delay' mean, anyways?
>>>
>>>Tim
>>>
>>
>>But they are not the same. Why can I get USER_HZ but not HZ?
>
>
> Because USER_HZ is there only because HZ changes on various systems and
> we don't want to break userland apps that assume its value.
>
>
>
>>On a 100HZ kernel ANY requested delay via udelay or
>>pthread_cond_timedwait of less than 10000usecs is unreliable and the the
>>actual results are totally unacceptable.
>>
>>On a 1000HZ kernel the number is 1000 usecs.
>>
>>I'm not asking the kernel running at 1000hz to actually give me 500 usec
>>delay if I ask. I do expect it to be at least 500 usec and within +- a
>>single HZ however. Oviously a 1000HZ machine is going to give me better
>>resulution in any requested delay. Why is it unreasonable for userland
>>to know the probable resolution of userland delay requests.
>
>
> But you don't really want to know HZ, you want to know timer resolution.
> That's a reasonable request and I believe the posix-timers
> clock_getres() interface might provide what you need. Although I'd defer
> to George (CC'ed) since he's more of an expert on those interfaces.
Exactly. clock_getres() on CLOCK_REALTIME will get the resolution of
timers (itimers or posix timers on CLOCK_REALTIME. You can also get the
res using the old itimer interface by programing a repeating time of 1
usec and then reading back the timer (get_timer ?). Set a longish
initial time so you can delete the timer prior to its expiring and look
at the repeat time returned. Do be aware that this will be rounded up,
however, and will likely show, e.g. 1000 usec for 999849 ns (as returned
by clock_getres()). Either of these interfaces is in the 2.6 kernel
these days.
>
> You might also want to check out his HRT patches.
Thanks for the plug :)
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
On Wed, 2005-09-14 at 12:00 +0800, Coywolf Qi Hunt wrote:
> simply zgrep HZ= /proc/config.gz
> on my box, I get CONFIG_HZ=1000
Many distros inexplicably disable that by default.
Lee
On Tue, 2005-09-13 at 16:38 -0400, linux-os (Dick Johnson) wrote:
> > That means Linux is not a suitable operating system for multimedia
> > applications.
> > MIDI needs to schedule in 1 ms or smaller increments. The userland
> > application
> > should be able to set this. It should be able to determine this. If it
> > cannot
> > then it is useless. (It also explains why MIDI based applications are so
> > absolutely dreadful on Linux.)
> >
> > {^_^} Joanne Dow said that.
> >
> >
>
> Well no. MIDI stuff has drivers that interface with precision timers
> in your audio board such as Creative Labs Soundblaster. They have
> a serial connection that, with a simple adapter becomes MIDI I/O.
> These boards, and even the ones built into motherboards can (do)
> generate and receive precision MIDI.
Um, we know how MIDI interfaces work, thanks very much.
Yes, ideally all MIDI would use the soundcard's interval timer for
timing. The problem is that so many of the soundcard drivers are
reverse engineered and we don't always know how to use it. Currently
only the emu10k1 and ymfpci ALSA drivers support the soudn cards
hardware timer. The emu10k1's interval timer was not supported at all
until ALSA 1.0.8 or so (I added the support). And the ALSA sequencer
still does not use the soundcard timer by default, you have to pass
module options. By default we have to use itimers because it works
everywhere.
And what if you're playing back a MIDI file from a sequencer into a
softsynth and sending the audio out through your cheap soundcard? No
MIDI ports or timers available. For example the intel8x0 doesn't have
an interval timer at all.
Userspace DOES need to know the timer resolution (but as others pointed
out you don't need to know HZ). If HZ is 100 then the best itimers can
do is ~10ms which is unacceptable for MIDI, so the program uses /dev/rtc
for timing instead.
If you had checked the linux-audio-dev archives before spouting off
you'd find TONS of apps that do just this.
Lee
Lee Revell wrote:
> On Wed, 2005-09-14 at 12:00 +0800, Coywolf Qi Hunt wrote:
>
>>simply zgrep HZ= /proc/config.gz
>>on my box, I get CONFIG_HZ=1000
>
>
> Many distros inexplicably disable that by default.
Their rationale is that knowing the kernel .config is a security threat.
Whatever. I'd rather have the convenience than the miniscule amount of
security that would supposedly provide
On Thu, 15 Sep 2005 09:16:25 PDT, Joe Bob Spamtest said:
> Lee Revell wrote:
> > On Wed, 2005-09-14 at 12:00 +0800, Coywolf Qi Hunt wrote:
> >
> >>simply zgrep HZ= /proc/config.gz
> >>on my box, I get CONFIG_HZ=1000
> >
> >
> > Many distros inexplicably disable that by default.
>
> Their rationale is that knowing the kernel .config is a security threat.
At least in Fedora, they ship a mode 644 config file in /boot:
% ls -l /boot/config-2.6.13-1.1555_FC5
61 -rw-r--r-- 1 root root 60135 Sep 14 15:55 /boot/config-2.6.13-1.1555_FC5
No need to include that in the kernel if it's right there on disk. Even Fedora
doesn't believe in *that* much bloat. ;)
On 9/15/05, [email protected] <[email protected]> wrote:
> On Thu, 15 Sep 2005 09:16:25 PDT, Joe Bob Spamtest said:
> > Lee Revell wrote:
> > > On Wed, 2005-09-14 at 12:00 +0800, Coywolf Qi Hunt wrote:
> > >
> > >>simply zgrep HZ= /proc/config.gz
> > >>on my box, I get CONFIG_HZ=1000
> > >
> > >
> > > Many distros inexplicably disable that by default.
> >
> > Their rationale is that knowing the kernel .config is a security threat.
>
> At least in Fedora, they ship a mode 644 config file in /boot:
>
> % ls -l /boot/config-2.6.13-1.1555_FC5
> 61 -rw-r--r-- 1 root root 60135 Sep 14 15:55 /boot/config-2.6.13-1.1555_FC5
>
> No need to include that in the kernel if it's right there on disk. Even Fedora
> doesn't believe in *that* much bloat. ;)
>
Or delete it from disk and include it in the kernel instead.
Having it in the kernel instead of as a sepperate file makes sense to
me; you'll never loose it as long as you have the actual kernel
around. Nothing like finding a problem with an older kernel and not
being able to duplicate the config with a newer one because you
deleted the .config at some point. With the config embedded in the
kernel that never happens...
As for the security issue with being able to read /proc/config.gz,
couldn't that be solved easily if that file had mode 0400 ?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html