[2.6 patch] kconfig-language.txt: remove bogus hint

[2.6 patch] kconfig-language.txt: remove bogus hint

[Adrian Bunk]

This kconfig construct described here is required in a different and 
much more complicated situation.

For the use case the hint claimed it would be a simple dependency is 
enough.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
8e3fd4a5e77c9cd1b52989cd72e984b47ad426b4 diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index 00b950d..c412c24 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -377,27 +377,3 @@ config FOO
 
 limits FOO to module (=m) or disabled (=n).
 
-
-Build limited by a third config symbol which may be =y or =m
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A common idiom that we see (and sometimes have problems with) is this:
-
-When option C in B (module or subsystem) uses interfaces from A (module
-or subsystem), and both A and B are tristate (could be =y or =m if they
-were independent of each other, but they aren't), then we need to limit
-C such that it cannot be built statically if A is built as a loadable
-module.  (C already depends on B, so there is no dependency issue to
-take care of here.)
-
-If A is linked statically into the kernel image, C can be built
-statically or as loadable module(s).  However, if A is built as loadable
-module(s), then C must be restricted to loadable module(s) also.  This
-can be expressed in kconfig language as:
-
-config C
-	depends on A = y || A = B
-
-or for real examples, use this command in a kernel tree:
-
-$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v orig
-

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Sam Ravnborg]

On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
> This kconfig construct described here is required in a different and 
> much more complicated situation.
Please elaborate...

	Sam

> 
> For the use case the hint claimed it would be a simple dependency is 
> enough.
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
> 
> ---
> 8e3fd4a5e77c9cd1b52989cd72e984b47ad426b4 diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
> index 00b950d..c412c24 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -377,27 +377,3 @@ config FOO
>  
>  limits FOO to module (=m) or disabled (=n).
>  
> -
> -Build limited by a third config symbol which may be =y or =m
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> -A common idiom that we see (and sometimes have problems with) is this:
> -
> -When option C in B (module or subsystem) uses interfaces from A (module
> -or subsystem), and both A and B are tristate (could be =y or =m if they
> -were independent of each other, but they aren't), then we need to limit
> -C such that it cannot be built statically if A is built as a loadable
> -module.  (C already depends on B, so there is no dependency issue to
> -take care of here.)
> -
> -If A is linked statically into the kernel image, C can be built
> -statically or as loadable module(s).  However, if A is built as loadable
> -module(s), then C must be restricted to loadable module(s) also.  This
> -can be expressed in kconfig language as:
> -
> -config C
> -	depends on A = y || A = B
> -
> -or for real examples, use this command in a kernel tree:
> -
> -$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v orig
> -
> 

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Adrian Bunk]

On Sun, May 04, 2008 at 08:17:41AM +0200, Sam Ravnborg wrote:
> On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
> > This kconfig construct described here is required in a different and 
> > much more complicated situation.
> Please elaborate...

In the hint C is described as a tristate.

But you need this idiom only when A is a tristate and C is a bool.

Understanding when to apply this idiom requiers an understanding that we 
use bool for two quite different cases:
- non-modular driver and
- enable feature in driver,
and the semantics bool's have in kconfig (e.g. select has the 
semantics for the former case and dependencies have the semantics
for the latter case, which does not sound logical but seems to actually 
cover most use cases).

> 	Sam
> 
> > 
> > For the use case the hint claimed it would be a simple dependency is 
> > enough.
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > 
> > ---
> > 8e3fd4a5e77c9cd1b52989cd72e984b47ad426b4 diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
> > index 00b950d..c412c24 100644
> > --- a/Documentation/kbuild/kconfig-language.txt
> > +++ b/Documentation/kbuild/kconfig-language.txt
> > @@ -377,27 +377,3 @@ config FOO
> >  
> >  limits FOO to module (=m) or disabled (=n).
> >  
> > -
> > -Build limited by a third config symbol which may be =y or =m
> > -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > -A common idiom that we see (and sometimes have problems with) is this:
> > -
> > -When option C in B (module or subsystem) uses interfaces from A (module
> > -or subsystem), and both A and B are tristate (could be =y or =m if they
> > -were independent of each other, but they aren't), then we need to limit
> > -C such that it cannot be built statically if A is built as a loadable
> > -module.  (C already depends on B, so there is no dependency issue to
> > -take care of here.)
> > -
> > -If A is linked statically into the kernel image, C can be built
> > -statically or as loadable module(s).  However, if A is built as loadable
> > -module(s), then C must be restricted to loadable module(s) also.  This
> > -can be expressed in kconfig language as:
> > -
> > -config C
> > -	depends on A = y || A = B
> > -
> > -or for real examples, use this command in a kernel tree:
> > -
> > -$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v orig
> > -
> > 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Sam Ravnborg]

On Sun, May 04, 2008 at 11:01:37AM +0300, Adrian Bunk wrote:
> On Sun, May 04, 2008 at 08:17:41AM +0200, Sam Ravnborg wrote:
> > On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
> > > This kconfig construct described here is required in a different and 
> > > much more complicated situation.
> > Please elaborate...
> 
> In the hint C is described as a tristate.
> 
> But you need this idiom only when A is a tristate and C is a bool.
Thats another case.
What is described is following simple situation:

config FOO
        bool "Modules"
        option modules

config A
        tristate "a"

config B
        tristate "b"
        depends on A

config C
        tristate "c"
        depends on B
        depends on A = y || A = B


C uses a symbol defined by A - let us name it foo().
If C is build-in and A is a module => 
	link error - unable to resolve foo.

So we say: 
if A is buildin C may be built-in or module.
if A is a module C may not be built-in.

This is what this hint describes.


I would certainly love to see some of the other typical cases
described too.

We need a description that covers the LED case. And I think
you would be the best to come up with a description considering
the time you have spent investigating it.
Could you try to come up with either a suggested wording
or a patch?

Thanks,
	Sam

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Adrian Bunk]

On Sun, May 04, 2008 at 01:27:41PM +0200, Sam Ravnborg wrote:
> On Sun, May 04, 2008 at 11:01:37AM +0300, Adrian Bunk wrote:
> > On Sun, May 04, 2008 at 08:17:41AM +0200, Sam Ravnborg wrote:
> > > On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
> > > > This kconfig construct described here is required in a different and 
> > > > much more complicated situation.
> > > Please elaborate...
> > 
> > In the hint C is described as a tristate.
> > 
> > But you need this idiom only when A is a tristate and C is a bool.
> Thats another case.
> What is described is following simple situation:
> 
> config FOO
>         bool "Modules"
>         option modules
> 
> config A
>         tristate "a"
> 
> config B
>         tristate "b"
>         depends on A
> 
> config C
>         tristate "c"
>         depends on B
>         depends on A = y || A = B
> 
> 
> C uses a symbol defined by A - let us name it foo().
> If C is build-in and A is a module => 
> 	link error - unable to resolve foo.
> 
> So we say: 
> if A is buildin C may be built-in or module.
> if A is a module C may not be built-in.
> 
> This is what this hint describes.

In your example C does not need any dependency on A at all since it 
is already handled through the dependency chain C->B->A.

> I would certainly love to see some of the other typical cases 
> described too.
> 
> We need a description that covers the LED case. And I think
> you would be the best to come up with a description considering
> the time you have spent investigating it.
> Could you try to come up with either a suggested wording
> or a patch?

Roman is the one who actually fixed it:
  http://lkml.org/lkml/2008/4/30/615

I'm not sure whether we have often the opportunity to solve something 
this way.

> Thanks,
> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Sam Ravnborg]

On Sun, May 04, 2008 at 03:10:14PM +0300, Adrian Bunk wrote:
> On Sun, May 04, 2008 at 01:27:41PM +0200, Sam Ravnborg wrote:
> > On Sun, May 04, 2008 at 11:01:37AM +0300, Adrian Bunk wrote:
> > > On Sun, May 04, 2008 at 08:17:41AM +0200, Sam Ravnborg wrote:
> > > > On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
> > > > > This kconfig construct described here is required in a different and 
> > > > > much more complicated situation.
> > > > Please elaborate...
> > > 
> > > In the hint C is described as a tristate.
> > > 
> > > But you need this idiom only when A is a tristate and C is a bool.
> > Thats another case.
> > What is described is following simple situation:
> > 
> > config FOO
> >         bool "Modules"
> >         option modules
> > 
> > config A
> >         tristate "a"
> > 
> > config B
> >         tristate "b"
> >         depends on A
> > 
> > config C
> >         tristate "c"
> >         depends on B
> >         depends on A = y || A = B
> > 
> > 
> > C uses a symbol defined by A - let us name it foo().
> > If C is build-in and A is a module => 
> > 	link error - unable to resolve foo.
> > 
> > So we say: 
> > if A is buildin C may be built-in or module.
> > if A is a module C may not be built-in.
> > 
> > This is what this hint describes.
> 
> In your example C does not need any dependency on A at all since it 
> is already handled through the dependency chain C->B->A.

You are right.
Randy - what problem was it this text tried to describe/solve?


> > I would certainly love to see some of the other typical cases 
> > described too.
> > 
> > We need a description that covers the LED case. And I think
> > you would be the best to come up with a description considering
> > the time you have spent investigating it.
> > Could you try to come up with either a suggested wording
> > or a patch?
> 
> Roman is the one who actually fixed it:
>   http://lkml.org/lkml/2008/4/30/615
> 
> I'm not sure whether we have often the opportunity to solve something 
> this way.
I see.

	Sam

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Randy Dunlap]

Sam Ravnborg wrote:
> On Sun, May 04, 2008 at 03:10:14PM +0300, Adrian Bunk wrote:
>> On Sun, May 04, 2008 at 01:27:41PM +0200, Sam Ravnborg wrote:
>>> On Sun, May 04, 2008 at 11:01:37AM +0300, Adrian Bunk wrote:
>>>> On Sun, May 04, 2008 at 08:17:41AM +0200, Sam Ravnborg wrote:
>>>>> On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
>>>>>> This kconfig construct described here is required in a different and 
>>>>>> much more complicated situation.
>>>>> Please elaborate...
>>>> In the hint C is described as a tristate.
>>>>
>>>> But you need this idiom only when A is a tristate and C is a bool.
>>> Thats another case.
>>> What is described is following simple situation:
>>>
>>> config FOO
>>>         bool "Modules"
>>>         option modules
>>>
>>> config A
>>>         tristate "a"
>>>
>>> config B
>>>         tristate "b"
>>>         depends on A
>>>
>>> config C
>>>         tristate "c"
>>>         depends on B
>>>         depends on A = y || A = B
>>>
>>>
>>> C uses a symbol defined by A - let us name it foo().
>>> If C is build-in and A is a module => 
>>> 	link error - unable to resolve foo.
>>>
>>> So we say: 
>>> if A is buildin C may be built-in or module.
>>> if A is a module C may not be built-in.
>>>
>>> This is what this hint describes.
>> In your example C does not need any dependency on A at all since it 
>> is already handled through the dependency chain C->B->A.
> 
> You are right.
> Randy - what problem was it this text tried to describe/solve?

I thought that it was related to USB_STORAGE, but I don't find it
in current kernels.

If the text is misleading, it should be yanked, of course.
And other places checked, e.g.:

$ find drivers/ -name Kconfig\* | xargs grep -s "depends on.*=.*||.*=" | grep -v \.orig

(samples:)
drivers/net/wan/Kconfig:        depends on HDLC && (LAPB=m && HDLC=m || LAPB=y)
drivers/net/wireless/b43/Kconfig:       depends on B43 && (RFKILL = y || RFKILL = B43) && RFKILL_INPUT && (INPUT_POLLDEV = y || INPUT_POLLDEV = B43)
drivers/scsi/Kconfig:   depends on SCSI_TGT = y || SCSI_TGT = SCSI_FC_ATTRS
drivers/scsi/Kconfig:   depends on SCSI_TGT = y || SCSI_TGT = SCSI_SRP_ATTRS
drivers/scsi/libsas/Kconfig:    depends on ATA = y || ATA = SCSI_SAS_LIBSAS
drivers/ssb/Kconfig:    depends on SSB && (PCI = y || PCI = SSB)
drivers/ssb/Kconfig:    depends on SSB && (PCMCIA = y || PCMCIA = SSB) && EXPERIMENTAL
drivers/usb/host/Kconfig:       depends on USB_OHCI_HCD && (SSB = y || SSB = USB_OHCI_HCD) && EXPERIMENTAL


>>> I would certainly love to see some of the other typical cases 
>>> described too.
>>>
>>> We need a description that covers the LED case. And I think
>>> you would be the best to come up with a description considering
>>> the time you have spent investigating it.
>>> Could you try to come up with either a suggested wording
>>> or a patch?
>> Roman is the one who actually fixed it:
>>   http://lkml.org/lkml/2008/4/30/615
>>
>> I'm not sure whether we have often the opportunity to solve something 
>> this way.
> I see.
> 
> 	Sam


-- 
~Randy

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Adrian Bunk]

On Sun, May 04, 2008 at 10:25:57AM -0700, Randy Dunlap wrote:
> Sam Ravnborg wrote:
>> On Sun, May 04, 2008 at 03:10:14PM +0300, Adrian Bunk wrote:
>>> On Sun, May 04, 2008 at 01:27:41PM +0200, Sam Ravnborg wrote:
>>>> On Sun, May 04, 2008 at 11:01:37AM +0300, Adrian Bunk wrote:
>>>>> On Sun, May 04, 2008 at 08:17:41AM +0200, Sam Ravnborg wrote:
>>>>>> On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
>>>>>>> This kconfig construct described here is required in a 
>>>>>>> different and much more complicated situation.
>>>>>> Please elaborate...
>>>>> In the hint C is described as a tristate.
>>>>>
>>>>> But you need this idiom only when A is a tristate and C is a bool.
>>>> Thats another case.
>>>> What is described is following simple situation:
>>>>
>>>> config FOO
>>>>         bool "Modules"
>>>>         option modules
>>>>
>>>> config A
>>>>         tristate "a"
>>>>
>>>> config B
>>>>         tristate "b"
>>>>         depends on A
>>>>
>>>> config C
>>>>         tristate "c"
>>>>         depends on B
>>>>         depends on A = y || A = B
>>>>
>>>>
>>>> C uses a symbol defined by A - let us name it foo().
>>>> If C is build-in and A is a module => 	link error - unable to 
>>>> resolve foo.
>>>>
>>>> So we say: if A is buildin C may be built-in or module.
>>>> if A is a module C may not be built-in.
>>>>
>>>> This is what this hint describes.
>>> In your example C does not need any dependency on A at all since it  
>>> is already handled through the dependency chain C->B->A.
>>
>> You are right.
>> Randy - what problem was it this text tried to describe/solve?
>
> I thought that it was related to USB_STORAGE, but I don't find it
> in current kernels.
>
> If the text is misleading, it should be yanked, of course.
> And other places checked, e.g.:
>...

The idiom has use cases, but you need the following prerequisites:
- A and B are tristates
- B does not depend on A
- C is a bool with the semantics "enable feature C in B"

And I doubt you can put that into a useful hint.

> ~Randy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Randy Dunlap]

Adrian Bunk wrote:
> On Sun, May 04, 2008 at 10:25:57AM -0700, Randy Dunlap wrote:
>> Sam Ravnborg wrote:
>>> On Sun, May 04, 2008 at 03:10:14PM +0300, Adrian Bunk wrote:
>>>> On Sun, May 04, 2008 at 01:27:41PM +0200, Sam Ravnborg wrote:
>>>>> On Sun, May 04, 2008 at 11:01:37AM +0300, Adrian Bunk wrote:
>>>>>> On Sun, May 04, 2008 at 08:17:41AM +0200, Sam Ravnborg wrote:
>>>>>>> On Sun, May 04, 2008 at 02:15:35AM +0300, Adrian Bunk wrote:
>>>>>>>> This kconfig construct described here is required in a 
>>>>>>>> different and much more complicated situation.
>>>>>>> Please elaborate...
>>>>>> In the hint C is described as a tristate.
>>>>>>
>>>>>> But you need this idiom only when A is a tristate and C is a bool.
>>>>> Thats another case.
>>>>> What is described is following simple situation:
>>>>>
>>>>> config FOO
>>>>>         bool "Modules"
>>>>>         option modules
>>>>>
>>>>> config A
>>>>>         tristate "a"
>>>>>
>>>>> config B
>>>>>         tristate "b"
>>>>>         depends on A
>>>>>
>>>>> config C
>>>>>         tristate "c"
>>>>>         depends on B
>>>>>         depends on A = y || A = B
>>>>>
>>>>>
>>>>> C uses a symbol defined by A - let us name it foo().
>>>>> If C is build-in and A is a module => 	link error - unable to 
>>>>> resolve foo.
>>>>>
>>>>> So we say: if A is buildin C may be built-in or module.
>>>>> if A is a module C may not be built-in.
>>>>>
>>>>> This is what this hint describes.
>>>> In your example C does not need any dependency on A at all since it  
>>>> is already handled through the dependency chain C->B->A.
>>> You are right.
>>> Randy - what problem was it this text tried to describe/solve?
>> I thought that it was related to USB_STORAGE, but I don't find it
>> in current kernels.
>>
>> If the text is misleading, it should be yanked, of course.
>> And other places checked, e.g.:
>> ...
> 
> The idiom has use cases, but you need the following prerequisites:
> - A and B are tristates
> - B does not depend on A
> - C is a bool with the semantics "enable feature C in B"
> 
> And I doubt you can put that into a useful hint.

OK, sounds like the patch is good then.

-- 
~Randy

Re: [2.6 patch] kconfig-language.txt: remove bogus hint

[Sam Ravnborg]

On Sun, May 04, 2008 at 10:55:19AM -0700, Randy Dunlap wrote:
> >
> >The idiom has use cases, but you need the following prerequisites:
> >- A and B are tristates
> >- B does not depend on A
> >- C is a bool with the semantics "enable feature C in B"
> >
> >And I doubt you can put that into a useful hint.
> 
> OK, sounds like the patch is good then.

Thanks for the explanations.

Patch applied.

	Sam