All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Adrian Bunk <bunk@kernel.org>, linux-kbuild@vger.kernel.org
Subject: Re: [2.6 patch] kconfig-language.txt: remove bogus hint
Date: Sun, 04 May 2008 10:25:57 -0700	[thread overview]
Message-ID: <481DF1A5.1030103@oracle.com> (raw)
In-Reply-To: <20080504122640.GA19513@uranus.ravnborg.org>

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

  reply	other threads:[~2008-05-04 17:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-03 23:15 [2.6 patch] kconfig-language.txt: remove bogus hint Adrian Bunk
2008-05-04  6:17 ` Sam Ravnborg
2008-05-04  8:01   ` Adrian Bunk
2008-05-04 11:27     ` Sam Ravnborg
2008-05-04 12:10       ` Adrian Bunk
2008-05-04 12:26         ` Sam Ravnborg
2008-05-04 17:25           ` Randy Dunlap [this message]
2008-05-04 17:51             ` Adrian Bunk
2008-05-04 17:55               ` Randy Dunlap
2008-05-04 19:08                 ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=481DF1A5.1030103@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=bunk@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.