Shouldn't kconfig defaults match recommendations in help text?

Shouldn't kconfig defaults match recommendations in help text?

[Jesper Juhl]

Hi everyone,

First of all; I'm sorry if this hits the list twice, my original mail 
seems to have gone missing somehow so this is a resend.


I've been wondering about situations like this for a while :


[quote]

The processor's performance-monitoring counters are special-purpose
global registers. This option adds support for virtual per-process
performance-monitoring counters which only run when the process
to which they belong is executing. This improves the accuracy of
performance measurements by reducing "noise" from other processes.

Say Y.

  Virtual performance counters support (PERFCTR_VIRTUAL) [N/y/?] (NEW)

[/quote]


I just picked the above randomly, there are several other cases like it.

The comment clearly makes a recommendation that the user enables (in this 
case) the option, yet the default is the exact opposite. What is the point 
in that?
I don't see anything but confusion amongst users as the result of such 
inconsistency.

Would patches to change default configuration choices to match the 
recommendation given in the help text (if any) be acceptable? If not I'd 
be interrested in the reasons why not.

If such patches are acceptable/wanted I'll be happy to supply them.


--
Jesper Juhl <juhl-lkml@dif.dk>

Re: Shouldn't kconfig defaults match recommendations in help text?

[Mikael Pettersson]

Jesper Juhl writes:
 > [quote]
 > 
 > The processor's performance-monitoring counters are special-purpose
 > global registers. This option adds support for virtual per-process
 > performance-monitoring counters which only run when the process
 > to which they belong is executing. This improves the accuracy of
 > performance measurements by reducing "noise" from other processes.
 > 
 > Say Y.
 > 
 >   Virtual performance counters support (PERFCTR_VIRTUAL) [N/y/?] (NEW)
 > 
 > [/quote]
 > 
 > 
 > I just picked the above randomly, there are several other cases like it.
 > 
 > The comment clearly makes a recommendation that the user enables (in this 
 > case) the option, yet the default is the exact opposite. What is the point 
 > in that?
 > I don't see anything but confusion amongst users as the result of such 
 > inconsistency.

This particular mismatch occurs because the Kconfig entry
doesn't have a "default" line, so Kconfig defaults to "n".

It makes little sense to disable PERFCTR_VIRTUAL when
PERFCTR is enabled, so providing a "default y" for
PERFCTR_VIRTUAL is the right thing to do.
(It's an option because the design allows several
independent high-level services on top of the low-level
code. Currently there's only one high-level service in
2.6-mm, but with several it's reasonable to allow users
to enable only those they actually want.)

 > Would patches to change default configuration choices to match the 
 > recommendation given in the help text (if any) be acceptable? If not I'd 
 > be interrested in the reasons why not.
 > 
 > If such patches are acceptable/wanted I'll be happy to supply them.

Feel free to do so :-)

/Mikael

Re: Shouldn't kconfig defaults match recommendations in help text?

[Jesper Juhl]

On Tue, 24 Aug 2004, Mikael Pettersson wrote:

> Jesper Juhl writes:
>  > [quote]
>  > 
>  > The processor's performance-monitoring counters are special-purpose
>  > global registers. This option adds support for virtual per-process
>  > performance-monitoring counters which only run when the process
>  > to which they belong is executing. This improves the accuracy of
>  > performance measurements by reducing "noise" from other processes.
>  > 
>  > Say Y.
>  > 
>  >   Virtual performance counters support (PERFCTR_VIRTUAL) [N/y/?] (NEW)
>  > 
>  > [/quote]
>  > 
>  > 
>  > I just picked the above randomly, there are several other cases like it.
>  > 
>  > The comment clearly makes a recommendation that the user enables (in this 
>  > case) the option, yet the default is the exact opposite. What is the point 
>  > in that?
>  > I don't see anything but confusion amongst users as the result of such 
>  > inconsistency.
> 
> This particular mismatch occurs because the Kconfig entry
> doesn't have a "default" line, so Kconfig defaults to "n".
> 
> It makes little sense to disable PERFCTR_VIRTUAL when
> PERFCTR is enabled, so providing a "default y" for
> PERFCTR_VIRTUAL is the right thing to do.
> (It's an option because the design allows several
> independent high-level services on top of the low-level
> code. Currently there's only one high-level service in
> 2.6-mm, but with several it's reasonable to allow users
> to enable only those they actually want.)
> 
I had not investigated it in detail since it was simply one randomly 
picked example out of several, but thank you for the detailed explanation.


>  > Would patches to change default configuration choices to match the 
>  > recommendation given in the help text (if any) be acceptable? If not I'd 
>  > be interrested in the reasons why not.
>  > 
>  > If such patches are acceptable/wanted I'll be happy to supply them.
> 
> Feel free to do so :-)
> 
I'll post such patches in a short while. Sepperate mails, one pr patch 
changing one kconfig default pr patch.


--
Jesper Juhl

Re: Shouldn't kconfig defaults match recommendations in help text?

[Sam Ravnborg]

On Tue, Aug 24, 2004 at 07:03:55PM +0200, Jesper Juhl wrote:
> I'll post such patches in a short while. Sepperate mails, one pr patch 
> changing one kconfig default pr patch.

One Kconfig file pr. patch makes more sense.

	Sam

Re: Shouldn't kconfig defaults match recommendations in help text?

[Jesper Juhl]

On Tue, 24 Aug 2004, Sam Ravnborg wrote:

> On Tue, Aug 24, 2004 at 07:03:55PM +0200, Jesper Juhl wrote:
> > I'll post such patches in a short while. Sepperate mails, one pr patch 
> > changing one kconfig default pr patch.
> 
> One Kconfig file pr. patch makes more sense.
> 
You are right, I'll do that.

Which brings me to another thing regarding configs and defaults - there 
does not seem to be much relation between the defaults in the various 
Kconfig files and the settings in arch/<foo>/defconfig which puzzles me, 
especially since "make defconfig" seems to use the stuff from 
arch/<foo>/defconfig and not what's specified in Kconfig...
Wouldn't it make sense to update the defconfig's to match the Kconfig's 
when I make these changes?

--
Jesper Juhl

Re: Shouldn't kconfig defaults match recommendations in help text?

[Sam Ravnborg]

On Tue, Aug 24, 2004 at 09:33:09PM +0200, Jesper Juhl wrote:
> 
> Which brings me to another thing regarding configs and defaults - there 
> does not seem to be much relation between the defaults in the various 
> Kconfig files and the settings in arch/<foo>/defconfig which puzzles me, 
> especially since "make defconfig" seems to use the stuff from 
> arch/<foo>/defconfig and not what's specified in Kconfig...
> Wouldn't it make sense to update the defconfig's to match the Kconfig's 
> when I make these changes?

defconfig is only subject for changes by arch-maintainers.
And defaults provided in Kconfig is mainly valid for i386 anyway -
so are the Kconfig help text.

	Sam

Re: Shouldn't kconfig defaults match recommendations in help text?

[Jesper Juhl]

On Tue, 24 Aug 2004, Sam Ravnborg wrote:

> On Tue, Aug 24, 2004 at 09:33:09PM +0200, Jesper Juhl wrote:
> > 
> > Which brings me to another thing regarding configs and defaults - there 
> > does not seem to be much relation between the defaults in the various 
> > Kconfig files and the settings in arch/<foo>/defconfig which puzzles me, 
> > especially since "make defconfig" seems to use the stuff from 
> > arch/<foo>/defconfig and not what's specified in Kconfig...
> > Wouldn't it make sense to update the defconfig's to match the Kconfig's 
> > when I make these changes?
> 
> defconfig is only subject for changes by arch-maintainers.
> And defaults provided in Kconfig is mainly valid for i386 anyway -
> so are the Kconfig help text.
> 
Ok, thank you for enlightening me on that. So defaults are chosen first 
from defconfig, and then from Kconfig for options not present in 
defconfig.

I guess I should limit myself to i386 for this or maybe just abandon it 
alltogether. 
It still seems like a good idea though to make the defaults (at least on 
i386) match the help text recommendations, but if defconfig is used over 
Kconfig and defconfig is more or less off-limits, and changing Kconfig 
would result in wrong defaults on other archs (which would then cause more 
work for arch maintainers with updating their defconfig), then maybe it's 
really not such a good idea after all to go about changing this.

I'll stay away from making these changes for now unless I run across some 
really obvious and non-problematic cases.

--
Jesper Juhl

Shouldn't kconfig defaults match recommendations in help text?

[Jesper Juhl]

Hi everyone,

I've been wondering about situations like this for a while :


<quote>

The processor's performance-monitoring counters are special-purpose
global registers. This option adds support for virtual per-process
performance-monitoring counters which only run when the process
to which they belong is executing. This improves the accuracy of
performance measurements by reducing "noise" from other processes.

Say Y.

  Virtual performance counters support (PERFCTR_VIRTUAL) [N/y/?] (NEW)

</quote>


I just picked the above randomly, there are several other cases like it.

The comment clearly makes a recommendation that the user enables (in this 
case) the option, yet the default is the exact opposite. What is the point 
in that?
I don't see anything but confusion amongst users as the result of such 
inconsistency.

Would patches to change default configuration choices to match the 
recommendation given in the help text (if any) be acceptable? If not I'd 
be interrested in the reasons why not.

If such patches are acceptable/wanted I'll be happy to supply them.


--
Jesper Juhl <juhl-lkml@dif.dk>

Re: Shouldn't kconfig defaults match recommendations in help text?

[Roman Zippel]

Hi,

On Mon, 23 Aug 2004, Jesper Juhl wrote:

> Would patches to change default configuration choices to match the 
> recommendation given in the help text (if any) be acceptable? If not I'd 
> be interrested in the reasons why not.

Different configurations require different defaults and the current help 
text is rather static. The basic problem is that most recommendations are 
rather ix86 specific. I think an overuse of defaults is the wrong way to 
go.

bye, Roman

Re: Shouldn't kconfig defaults match recommendations in help text?

[Jesper Juhl]

On Tue, 24 Aug 2004, Roman Zippel wrote:

> Hi,
> 
> On Mon, 23 Aug 2004, Jesper Juhl wrote:
> 
> > Would patches to change default configuration choices to match the 
> > recommendation given in the help text (if any) be acceptable? If not I'd 
> > be interrested in the reasons why not.
> 
> Different configurations require different defaults and the current help 
> text is rather static. The basic problem is that most recommendations are 
> rather ix86 specific. I think an overuse of defaults is the wrong way to 
> go.
> 
I'll be sure to keep that in mind.
I will not go crazy with this and make everything default to the 
recommendations but try and only do it where it actually makes good sense 
- I'm hoping for people to review these patches and comment on the 
"saneness". 

--
Jesper Juhl