A kernel build is reporting the following:
net/rfkill/Kconfig:4:error: recursive dependency detected!
net/rfkill/Kconfig:4: symbol RFKILL is selected by R8723AU
drivers/staging/rtl8723au/Kconfig:1: symbol R8723AU depends on USB
drivers/usb/Kconfig:41: symbol USB is selected by MOUSE_APPLETOUCH
drivers/input/mouse/Kconfig:162: symbol MOUSE_APPLETOUCH depends on INPUT
drivers/input/Kconfig:8: symbol INPUT is selected by ACPI_CMPC
drivers/platform/x86/Kconfig:635: symbol ACPI_CMPC depends on RFKILL
What is the recommended way to avoid this circularity? Of course, R8723AU could
select USB rather than depending on it, but that does not seem quite right.
Thanks,
Larry
On Sun, 2014-04-06 at 14:49 -0500, Larry Finger wrote:
> A kernel build is reporting the following:
>
> net/rfkill/Kconfig:4:error: recursive dependency detected!
> net/rfkill/Kconfig:4: symbol RFKILL is selected by R8723AU
> drivers/staging/rtl8723au/Kconfig:1: symbol R8723AU depends on USB
> drivers/usb/Kconfig:41: symbol USB is selected by MOUSE_APPLETOUCH
> drivers/input/mouse/Kconfig:162: symbol MOUSE_APPLETOUCH depends on INPUT
> drivers/input/Kconfig:8: symbol INPUT is selected by ACPI_CMPC
> drivers/platform/x86/Kconfig:635: symbol ACPI_CMPC depends on RFKILL
I must be having a slow day, but how should this be parsed to see the
recursive dependency?
> What is the recommended way to avoid this circularity? Of course, R8723AU could
> select USB rather than depending on it, but that does not seem quite right.
Thanks,
Paul Bolle
On Sun, 2014-04-06 at 22:10 +0200, Paul Bolle wrote:
> On Sun, 2014-04-06 at 14:49 -0500, Larry Finger wrote:
> > A kernel build is reporting the following:
> >
> > net/rfkill/Kconfig:4:error: recursive dependency detected!
> > net/rfkill/Kconfig:4: symbol RFKILL is selected by R8723AU
> > drivers/staging/rtl8723au/Kconfig:1: symbol R8723AU depends on USB
> > drivers/usb/Kconfig:41: symbol USB is selected by MOUSE_APPLETOUCH
> > drivers/input/mouse/Kconfig:162: symbol MOUSE_APPLETOUCH depends on INPUT
> > drivers/input/Kconfig:8: symbol INPUT is selected by ACPI_CMPC
> > drivers/platform/x86/Kconfig:635: symbol ACPI_CMPC depends on RFKILL
>
> I must be having a slow day, but how should this be parsed to see the
> recursive dependency?
So it tells us ("depends on" vertical, "is selected by" horizontal):
R8723AU -> RFKILL
|
v
MOUSE_APPLETOUCH -> USB
|
v
ACPCI_CMPC -> INPUT
|
v
RFKILL
doesn't it? And why is that a problem?
Paul Bolle
On 04/06/2014 12:49 PM, Larry Finger wrote:
> A kernel build is reporting the following:
>
> net/rfkill/Kconfig:4:error: recursive dependency detected!
> net/rfkill/Kconfig:4: symbol RFKILL is selected by R8723AU
> drivers/staging/rtl8723au/Kconfig:1: symbol R8723AU depends on USB
> drivers/usb/Kconfig:41: symbol USB is selected by MOUSE_APPLETOUCH
> drivers/input/mouse/Kconfig:162: symbol MOUSE_APPLETOUCH depends on INPUT
> drivers/input/Kconfig:8: symbol INPUT is selected by ACPI_CMPC
> drivers/platform/x86/Kconfig:635: symbol ACPI_CMPC depends on RFKILL
>
> What is the recommended way to avoid this circularity? Of course, R8723AU could select USB rather than depending on it, but that does not seem quite right.
I don't know if it will fix the problem, but Linus has spoken (written)
against selecting subsystems, like INPUT or USB.
Does changing ACPI_CMPC to depend on INPUT instead of select INPUT
help?
and/or changing MOUSE_APPLETOUCH to depend on USB instead of select it?
--
~Randy
On Sun, 2014-04-06 at 13:31 -0700, Randy Dunlap wrote:
> and/or changing MOUSE_APPLETOUCH to depend on USB instead of select it?
MOUSE_APPLETOUCH selects USB and depends on USB_ARCH_HAS_HCD. That's
actually quite a common pattern.
But what is the purpose of USB_ARCH_HAS_HCD? It is set by default if
USB_SUPPORT is set. And USB depends on it, but since USB also depends on
USB_SUPPORT that seems superfluous.
My slow day continues, because I find this hard to grok.
Paul Bolle
On 04/06/2014 03:31 PM, Randy Dunlap wrote:
> On 04/06/2014 12:49 PM, Larry Finger wrote:
>> A kernel build is reporting the following:
>>
>> net/rfkill/Kconfig:4:error: recursive dependency detected!
>> net/rfkill/Kconfig:4: symbol RFKILL is selected by R8723AU
>> drivers/staging/rtl8723au/Kconfig:1: symbol R8723AU depends on USB
>> drivers/usb/Kconfig:41: symbol USB is selected by MOUSE_APPLETOUCH
>> drivers/input/mouse/Kconfig:162: symbol MOUSE_APPLETOUCH depends on INPUT
>> drivers/input/Kconfig:8: symbol INPUT is selected by ACPI_CMPC
>> drivers/platform/x86/Kconfig:635: symbol ACPI_CMPC depends on RFKILL
>>
>> What is the recommended way to avoid this circularity? Of course, R8723AU could select USB rather than depending on it, but that does not seem quite right.
>
> I don't know if it will fix the problem, but Linus has spoken (written)
> against selecting subsystems, like INPUT or USB.
>
> Does changing ACPI_CMPC to depend on INPUT instead of select INPUT
> help?
> and/or changing MOUSE_APPLETOUCH to depend on USB instead of select it?
This case seems to prove why Linus has so spoken!
Changing ACPI_CMPC to depend on INPUT does fix the build. Making the change to
MOUSE_APPLETOUCH ends up getting a different recursive error.
Thanks for your suggestion. As I do not "own" the x86 platform drivers, I will
have to post a patch to fix the ACPI_CMPC problem, but at least I know what to
say in the commit message that adds the RFKILL selection to the R8723AU Kconfig.
Larry
On 04/06/2014 03:52 PM, Paul Bolle wrote:
> On Sun, 2014-04-06 at 13:31 -0700, Randy Dunlap wrote:
>> and/or changing MOUSE_APPLETOUCH to depend on USB instead of select it?
>
> MOUSE_APPLETOUCH selects USB and depends on USB_ARCH_HAS_HCD. That's
> actually quite a common pattern.
>
> But what is the purpose of USB_ARCH_HAS_HCD? It is set by default if
> USB_SUPPORT is set. And USB depends on it, but since USB also depends on
> USB_SUPPORT that seems superfluous.
>
> My slow day continues, because I find this hard to grok.
As you have seen in my reply to Randy, this appears to arise from violating one
of the edicts of Linus that says that no configuration variable should select a
subsystem. Of course, one could argue that RFKILL is also a subsystem, and that
R8723AU should depend on it rather that selecting it.
My day also seems to be slowing. :)
Larry
On Sun, 2014-04-06 at 16:07 -0500, Larry Finger wrote:
> As you have seen in my reply to Randy, this appears to arise from violating one
> of the edicts of Linus that says that no configuration variable should select a
> subsystem. Of course, one could argue that RFKILL is also a subsystem, and that
> R8723AU should depend on it rather that selecting it.
>
> My day also seems to be slowing. :)
Would you mind sharing the .config that triggered this? (I guess I also
need to know the make command you ran.) Than I could play with this, on
a not so slow day, and maybe, just maybe, understand what's going on.
Paul Bolle
On 04/06/2014 04:14 PM, Paul Bolle wrote:
> On Sun, 2014-04-06 at 16:07 -0500, Larry Finger wrote:
>> As you have seen in my reply to Randy, this appears to arise from violating one
>> of the edicts of Linus that says that no configuration variable should select a
>> subsystem. Of course, one could argue that RFKILL is also a subsystem, and that
>> R8723AU should depend on it rather that selecting it.
>>
>> My day also seems to be slowing. :)
>
> Would you mind sharing the .config that triggered this? (I guess I also
> need to know the make command you ran.) Than I could play with this, on
> a not so slow day, and maybe, just maybe, understand what's going on.
No problem - it is attached. The problem I was trying to solve was reported by
the kbuild test robot. To get the driver r8723au, you will need the staging-next
tree.
Larry
On Sunday 06 April 2014, Paul Bolle wrote:
>On Sun, 2014-04-06 at 13:31 -0700, Randy Dunlap wrote:
>> and/or changing MOUSE_APPLETOUCH to depend on USB instead of select it?
>
>MOUSE_APPLETOUCH selects USB and depends on USB_ARCH_HAS_HCD. That's
>actually quite a common pattern.
>
>But what is the purpose of USB_ARCH_HAS_HCD? It is set by default if
>USB_SUPPORT is set. And USB depends on it, but since USB also depends on
>USB_SUPPORT that seems superfluous.
>
>My slow day continues, because I find this hard to grok.
>
>
>Paul Bolle
Rant mode on.
I don't find it at all hard to use my toothpick sized oar here to bitch
about de-selected subsystems that are buried so far in dependencies that
you simply cannot find the options you need in a make xconfig or make
menuconfig.
To have a whole genre of drivers simply disappear, never to be seen again
by someone trying to configure a working kernel, just because some
upstream, totally unrelated upstream dependency isn't checked, is nothing
short of asinine.
I just spent a month building a new kernel here, and finally had to resort
to editing the individual trees kconfig files to get a 3.13.6 PAE kernel to
build, and it STILL won't play videos without extremely distracting audio
stutters and many second long video freezes, followed by 300 frames a
second catchups.
Reboot to Ubu1204.3 LTS, works perfectly, except kmail crashes even before
opening its screen, with an error no one on the kubuntu lists has ever
seen. I can't work without a working email agent.
I had to search thru the far ends of the driver trees, looking at kconfig
files to see what parent dependencies they might contain, cd back up the
tree one level and make sure that kconfig had its dependencies met, clear
back up to the root kconfig. This went on, building and rebooting to at
least 3 kernels an evening for damned near a month to even get where I am
ATM. Thats not excusable. Do not ever hide shit, make it ALL visible, and
if I check a driver my hardware needs, it should cascade back up thru the
tree calling in every other thing that driver needs, whether its selected
in the parent kconfigs or not. If that attitude steps on somebodies toes,
I don't have a quarter to call anybody who cares.
This from someone who has been a linux only house since RH5.0, in what,
1997 or 1998?
You have, in the last few years, been painting yourself into a corner with
the *config's. FIX IT.
/Rant mode off.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
On Sun, 2014-04-06 at 17:51 -0500, Larry Finger wrote:
> No problem - it is attached. The problem I was trying to solve was reported by
> the kbuild test robot. To get the driver r8723au, you will need the staging-next
> tree.
0) I couldn't reproduce your error with this config file (and the
next-20140407 tree). But I could reproduce by cbobbling together a
single rudimentary Kconfig file with the six symbols mentioned in the
error you had copied. And then I could cut things down to this minimal
test case:
$ cat Kconfig.recursive
# test with 'yes "" | make KBUILD_KCONFIG=Kconfig.recursive oldconfig'
mainmenu "Recursive dependency test case"
config DRIVER1
bool "Driver 1"
select SUBSYSTEM2
depends on SUBSYSTEM1
config DRIVER2
bool "Driver 2"
select SUBSYSTEM1
depends on SUBSYSTEM2
config SUBSYSTEM1
bool "Subsystem 1"
config SUBSYSTEM2
bool "Subsystem 2"
1) This made zero sense, until I realized that "select" statements are
treated as reverse dependencies in the kconfig code. And if you look at
these two select statements as reverse dependencies than, yes, this is a
Kconfig with a recursive dependency.
2) But the fact is that I actually don't think of "select" statements as
reverse dependencies. And in the Kconfig files they are not used as
reverse dependencies. See, for example, all the
select USB
statements in the tree. I think there are many similar uses of "select".
3) So I think it makes no sense to treat "select" relations as reverse
dependencies. But perhaps I am missing something here.
Paul Bolle