LinuxLists.cc - Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 8, 2010 at 10:12 AM, Corentin Chary
<[email protected]> wrote:
> On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <[email protected]> wrote:
>> Hi,
>>
>> just wanted to build a new linux-next and see this:
>>
>> [ setup.log ]
>> ...
>> dileks.1" make -C 'debian/build/source_i386_none'
>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>> oldnoconfig
>> make[2]: Entering directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> HOSTCC scripts/basic/fixdep
>> HOSTCC scripts/basic/docproc
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> HOSTCC scripts/kconfig/conf.o
>> HOSTCC scripts/kconfig/kxgettext.o
>> SHIPPED scripts/kconfig/zconf.tab.c
>> SHIPPED scripts/kconfig/lex.zconf.c
>> SHIPPED scripts/kconfig/zconf.hash.c
>> HOSTCC scripts/kconfig/zconf.tab.o
>> HOSTLD scripts/kconfig/conf
>> scripts/kconfig/conf --oldnoconfig Kconfig
>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>> which has unmet direct dependencies (NEW_LEDS)
>> #
>> # configuration written to .config
>> #
>> make[2]: Leaving directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u
>> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1
>> [email protected]
>> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C
>> 'debian/build/source_i386_none'
>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>> prepare
>> make[2]: Entering directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> scripts/kconfig/conf --silentoldconfig Kconfig
>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>> which has unmet direct dependencies (NEW_LEDS)
>> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none
>> as source for kernel
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> CHK include/linux/version.h
>> UPD include/linux/version.h
>> CHK include/generated/utsrelease.h
>> UPD include/generated/utsrelease.h
>> CC kernel/bounds.s
>> GEN include/generated/bounds.h
>> CC arch/x86/kernel/asm-offsets.s
>> GEN include/generated/asm-offsets.h
>> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh
>> make[2]: Leaving directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5'
>>
>> Regards,
>> - Sedat -
>> --
>> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Hum ...
> ACER_WMI:
> select ACPI_WMI
> depends on LEDS_CLASS
> depends on NEW_LEDS
>
> EEEPC_WMI:
> depends on ACPI_WMI
> select LEDS_CLASS
> select NEW_LEDS
>
> I don't really see how it's a recursive dependency, but maybe it's
> time to clean this KConfig.
> What is our current policy about that ?
>
> I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> and select obscure things so
> that the driver does not get lost if you don't enable the leds.
>
> depends:
> - ACPI
> - INPUT
> - EXPERIMENTAL
> - RFKILL
> - ACPI_WMI ?
> - HWMON ?
> - THERMAL ?
>
> select:
> - BACKLIGHT_CLASS_*
> - LEDS_CLASS
> - NEW_LEDS
> - INPUT_*
>
> --
> Corentin Chary
> http://xf.iksaif.net
>

[ CC Johannes Berg ]

Cloning platform-driver-x86 GIT tree and will play with the Kconfig...

Wasn't all depends/selects to LEDS_CLASS outsourced by Johannes Berg
to drivers/leds/Kconfig recently?

- Sedat -

2010-12-08 09:21:19

by Berg, Johannes

[permalink] [raw]

Subject: RE: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

> > Hum ...
> > ACER_WMI:
> > select ACPI_WMI
> > depends on LEDS_CLASS
> > depends on NEW_LEDS
> >
> > EEEPC_WMI:
> > depends on ACPI_WMI
> > select LEDS_CLASS
> > select NEW_LEDS

Curious.

> > I don't really see how it's a recursive dependency, but maybe it's
> > time to clean this KConfig.
> > What is our current policy about that ?
> >
> > I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> > and select obscure things so
> > that the driver does not get lost if you don't enable the leds.

I'm happy with that. Frankly, I don't want to care about LED, but...

> Wasn't all depends/selects to LEDS_CLASS outsourced by Johannes Berg
> to drivers/leds/Kconfig recently?

No, I just cleaned it up to make it not break builds and disallow
some weird configurations.

johannes
--------------------------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?

2010-12-08 09:28:51

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 8, 2010 at 10:12 AM, Corentin Chary
<[email protected]> wrote:
> On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <[email protected]> wrote:
>> Hi,
>>
>> just wanted to build a new linux-next and see this:
>>
>> [ setup.log ]
>> ...
>> dileks.1" make -C 'debian/build/source_i386_none'
>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>> oldnoconfig
>> make[2]: Entering directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> HOSTCC scripts/basic/fixdep
>> HOSTCC scripts/basic/docproc
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> HOSTCC scripts/kconfig/conf.o
>> HOSTCC scripts/kconfig/kxgettext.o
>> SHIPPED scripts/kconfig/zconf.tab.c
>> SHIPPED scripts/kconfig/lex.zconf.c
>> SHIPPED scripts/kconfig/zconf.hash.c
>> HOSTCC scripts/kconfig/zconf.tab.o
>> HOSTLD scripts/kconfig/conf
>> scripts/kconfig/conf --oldnoconfig Kconfig
>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>> which has unmet direct dependencies (NEW_LEDS)
>> #
>> # configuration written to .config
>> #
>> make[2]: Leaving directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u
>> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1
>> [email protected]
>> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C
>> 'debian/build/source_i386_none'
>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>> prepare
>> make[2]: Entering directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> scripts/kconfig/conf --silentoldconfig Kconfig
>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>> which has unmet direct dependencies (NEW_LEDS)
>> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none
>> as source for kernel
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> CHK include/linux/version.h
>> UPD include/linux/version.h
>> CHK include/generated/utsrelease.h
>> UPD include/generated/utsrelease.h
>> CC kernel/bounds.s
>> GEN include/generated/bounds.h
>> CC arch/x86/kernel/asm-offsets.s
>> GEN include/generated/asm-offsets.h
>> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh
>> make[2]: Leaving directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5'
>>
>> Regards,
>> - Sedat -
>> --
>> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Hum ...
> ACER_WMI:
> select ACPI_WMI
> depends on LEDS_CLASS
> depends on NEW_LEDS
>
> EEEPC_WMI:
> depends on ACPI_WMI
> select LEDS_CLASS
> select NEW_LEDS
>
> I don't really see how it's a recursive dependency, but maybe it's
> time to clean this KConfig.
> What is our current policy about that ?
>
> I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> and select obscure things so
> that the driver does not get lost if you don't enable the leds.
>
> depends:
> - ACPI
> - INPUT
> - EXPERIMENTAL
> - RFKILL
> - ACPI_WMI ?
> - HWMON ?
> - THERMAL ?
>
> select:
> - BACKLIGHT_CLASS_*
> - LEDS_CLASS
> - NEW_LEDS
> - INPUT_*
>
> --
> Corentin Chary
> http://xf.iksaif.net
>

The last 3 commits touching drivers/platform/x86/Kconfig:

$ git log -3 drivers/platform/x86/Kconfig

commit 8c75facc93240c864bcbc9b45c492b32725ad2d4
Author: Corentin Chary <[email protected]>
Date: Mon Nov 29 08:14:07 2010 +0100

eeepc-wmi: add rfkill support for wlan, bluetooth and 3g

wimax support is missing because I don't have any DSDT
with WMI and wimax support.

Most of the code comes from eeepc-laptop.

Signed-off-by: Corentin Chary <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>

commit 41eeea57adfb7d37b4a826877a8a6965cae5fb4a
Author: Corentin Chary <[email protected]>
Date: Mon Nov 29 08:14:06 2010 +0100

eeepc-wmi: add touchpad led support

Most of the code comes from eeepc-laptop.

Signed-off-by: Corentin Chary <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>

commit 02846193f7b31e7f12a007894bdb1b4f4d7d6c22
Author: Sreedhara DS <[email protected]>
Date: Fri Oct 22 15:43:55 2010 +0100

intel_scu_ipc: Utility driver for intel scu ipc
...

2010-12-08 09:51:31

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 8, 2010 at 10:28 AM, Sedat Dilek <[email protected]> wrote:
> On Wed, Dec 8, 2010 at 10:12 AM, Corentin Chary
> <[email protected]> wrote:
>> On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <[email protected]> wrote:
>>> Hi,
>>>
>>> just wanted to build a new linux-next and see this:
>>>
>>> [ setup.log ]
>>> ...
>>> dileks.1" make -C 'debian/build/source_i386_none'
>>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>>> oldnoconfig
>>> make[2]: Entering directory
>>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>>> HOSTCC scripts/basic/fixdep
>>> HOSTCC scripts/basic/docproc
>>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>>> HOSTCC scripts/kconfig/conf.o
>>> HOSTCC scripts/kconfig/kxgettext.o
>>> SHIPPED scripts/kconfig/zconf.tab.c
>>> SHIPPED scripts/kconfig/lex.zconf.c
>>> SHIPPED scripts/kconfig/zconf.hash.c
>>> HOSTCC scripts/kconfig/zconf.tab.o
>>> HOSTLD scripts/kconfig/conf
>>> scripts/kconfig/conf --oldnoconfig Kconfig
>>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>>> which has unmet direct dependencies (NEW_LEDS)
>>> #
>>> # configuration written to .config
>>> #
>>> make[2]: Leaving directory
>>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>>> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u
>>> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1
>>> [email protected]
>>> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C
>>> 'debian/build/source_i386_none'
>>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>>> prepare
>>> make[2]: Entering directory
>>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>>> scripts/kconfig/conf --silentoldconfig Kconfig
>>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>>> which has unmet direct dependencies (NEW_LEDS)
>>> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none
>>> as source for kernel
>>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>>> CHK include/linux/version.h
>>> UPD include/linux/version.h
>>> CHK include/generated/utsrelease.h
>>> UPD include/generated/utsrelease.h
>>> CC kernel/bounds.s
>>> GEN include/generated/bounds.h
>>> CC arch/x86/kernel/asm-offsets.s
>>> GEN include/generated/asm-offsets.h
>>> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh
>>> make[2]: Leaving directory
>>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>>> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5'
>>>
>>> Regards,
>>> - Sedat -
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Hum ...
>> ACER_WMI:
>> select ACPI_WMI
>> depends on LEDS_CLASS
>> depends on NEW_LEDS
>>
>> EEEPC_WMI:
>> depends on ACPI_WMI
>> select LEDS_CLASS
>> select NEW_LEDS
>>
>> I don't really see how it's a recursive dependency, but maybe it's
>> time to clean this KConfig.
>> What is our current policy about that ?
>>
>> I think we should *depends* on important subsystem (ACPI, INPUT, ...)
>> and select obscure things so
>> that the driver does not get lost if you don't enable the leds.
>>
>> depends:
>> - ACPI
>> - INPUT
>> - EXPERIMENTAL
>> - RFKILL
>> - ACPI_WMI ?
>> - HWMON ?
>> - THERMAL ?
>>
>> select:
>> - BACKLIGHT_CLASS_*
>> - LEDS_CLASS
>> - NEW_LEDS
>> - INPUT_*
>>
>> --
>> Corentin Chary
>> http://xf.iksaif.net
>>
>
> The last 3 commits touching drivers/platform/x86/Kconfig:
>
> $ git log -3 drivers/platform/x86/Kconfig
>
> commit 8c75facc93240c864bcbc9b45c492b32725ad2d4
> Author: Corentin Chary <[email protected]>
> Date: Mon Nov 29 08:14:07 2010 +0100
>
> eeepc-wmi: add rfkill support for wlan, bluetooth and 3g
>
> wimax support is missing because I don't have any DSDT
> with WMI and wimax support.
>
> Most of the code comes from eeepc-laptop.
>
> Signed-off-by: Corentin Chary <[email protected]>
> Signed-off-by: Matthew Garrett <[email protected]>
>
> commit 41eeea57adfb7d37b4a826877a8a6965cae5fb4a
> Author: Corentin Chary <[email protected]>
> Date: Mon Nov 29 08:14:06 2010 +0100
>
> eeepc-wmi: add touchpad led support
>
> Most of the code comes from eeepc-laptop.
>
> Signed-off-by: Corentin Chary <[email protected]>
> Signed-off-by: Matthew Garrett <[email protected]>
>
> commit 02846193f7b31e7f12a007894bdb1b4f4d7d6c22
> Author: Sreedhara DS <[email protected]>
> Date: Fri Oct 22 15:43:55 2010 +0100
>
> intel_scu_ipc: Utility driver for intel scu ipc
> ...
>

The following patch fixes the issue here (setup.log attached).

- Sedat -

Attachments:

platform-x86-Kconfig-Replace-select-by-depends-on-ACPI_WMI.patch (764.00 B)
setup.log (9.49 kB)
Download all attachments

2010-12-08 09:53:36

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote:
>
> I don't really see how it's a recursive dependency, but maybe it's
> time to clean this KConfig.
> What is our current policy about that ?
>
> I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> and select obscure things so
> that the driver does not get lost if you don't enable the leds.

A better policy is: "NEVER USE SELECT".

--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation

2010-12-08 10:12:54

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 8, 2010 at 10:53 AM, David Woodhouse <[email protected]> wrote:
> On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote:
>>
>> I don't really see how it's a recursive dependency, but maybe it's
>> time to clean this KConfig.
>> What is our current policy about that ?
>>
>> I think we should *depends* on important subsystem (ACPI, INPUT, ...)
>> and select obscure things so
>> that the driver does not get lost if you don't enable the leds.
>
> A better policy is: "NEVER USE SELECT".

Yes, confirmed (see my patch to MLs).

- Sedat -

2010-12-08 17:31:58

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On 12/08/10 01:12, Corentin Chary wrote:
> On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <[email protected]> wrote:
>> Hi,
>>
>> just wanted to build a new linux-next and see this:
>>
>> [ setup.log ]
>> ...
>> dileks.1" make -C 'debian/build/source_i386_none'
>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>> oldnoconfig
>> make[2]: Entering directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> HOSTCC scripts/basic/fixdep
>> HOSTCC scripts/basic/docproc
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> HOSTCC scripts/kconfig/conf.o
>> HOSTCC scripts/kconfig/kxgettext.o
>> SHIPPED scripts/kconfig/zconf.tab.c
>> SHIPPED scripts/kconfig/lex.zconf.c
>> SHIPPED scripts/kconfig/zconf.hash.c
>> HOSTCC scripts/kconfig/zconf.tab.o
>> HOSTLD scripts/kconfig/conf
>> scripts/kconfig/conf --oldnoconfig Kconfig
>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>> which has unmet direct dependencies (NEW_LEDS)
>> #
>> # configuration written to .config
>> #
>> make[2]: Leaving directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u
>> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1
>> [email protected]
>> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C
>> 'debian/build/source_i386_none'
>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686'
>> prepare
>> make[2]: Entering directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> scripts/kconfig/conf --silentoldconfig Kconfig
>> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
>> drivers/platform/x86/Kconfig:422: symbol EEEPC_WMI depends on ACPI_WMI
>> drivers/platform/x86/Kconfig:438: symbol ACPI_WMI is selected by ACER_WMI
>> drivers/platform/x86/Kconfig:18: symbol ACER_WMI depends on LEDS_CLASS
>> drivers/leds/Kconfig:10: symbol LEDS_CLASS is selected by EEEPC_WMI
>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K &&
>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) &&
>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI &&
>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB &&
>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON &&
>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86
>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 ||
>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR &&
>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 &&
>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C ||
>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM &&
>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI &&
>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 &&
>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) ||
>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT &&
>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI &&
>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL &&
>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS
>> which has unmet direct dependencies (NEW_LEDS)
>> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none
>> as source for kernel
>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile
>> CHK include/linux/version.h
>> UPD include/linux/version.h
>> CHK include/generated/utsrelease.h
>> UPD include/generated/utsrelease.h
>> CC kernel/bounds.s
>> GEN include/generated/bounds.h
>> CC arch/x86/kernel/asm-offsets.s
>> GEN include/generated/asm-offsets.h
>> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh
>> make[2]: Leaving directory
>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none'
>> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5'
>>
>> Regards,
>> - Sedat -
>> --
>> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Hum ...
> ACER_WMI:
> select ACPI_WMI
> depends on LEDS_CLASS
> depends on NEW_LEDS
>
> EEEPC_WMI:
> depends on ACPI_WMI
> select LEDS_CLASS
> select NEW_LEDS
>
> I don't really see how it's a recursive dependency, but maybe it's
> time to clean this KConfig.

It's circular.

> What is our current policy about that ?

Documentation/kbuild/kconfig-language.txt says:

Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.

I think that it would help if all of drivers/platform/x86/Kconfig treated
ACPI_WMI the same way. Currently 2 drivers select it and 4 drivers depend
on it.

Ah, that's what Sedat's patch does. Good.

> I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> and select obscure things so
> that the driver does not get lost if you don't enable the leds.
>
> depends:
> - ACPI
> - INPUT
> - EXPERIMENTAL
> - RFKILL
> - ACPI_WMI ?
> - HWMON ?
> - THERMAL ?
>
> select:
> - BACKLIGHT_CLASS_*
> - LEDS_CLASS
> - NEW_LEDS
> - INPUT_*
>

--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

2010-12-08 17:46:17

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote:
> On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote:
> >
> > I don't really see how it's a recursive dependency, but maybe it's
> > time to clean this KConfig.
> > What is our current policy about that ?
> >
> > I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> > and select obscure things so
> > that the driver does not get lost if you don't enable the leds.
>
> A better policy is: "NEVER USE SELECT".
>

No, this is BS. User selecting, for example, a button driver should not
care that it is working in polling mode only and needs polled device
library to work. As it was said before, drivers need to depend on major
subsystems and select minors and library modules.

The fact that our Kconfig can't really provide us with the functionality
we desire (be it because the logic is fuzzy and hard to formalize or
some other reason) shoud not force "NO SELECT" policy, we just need to
be careful when using it.

Thanks.

--
Dmitry

2010-12-08 21:52:43

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, 8 Dec 2010 09:46:04 -0800 Dmitry Torokhov wrote:

> On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote:
> > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote:
> > >
> > > I don't really see how it's a recursive dependency, but maybe it's
> > > time to clean this KConfig.
> > > What is our current policy about that ?
> > >
> > > I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> > > and select obscure things so
> > > that the driver does not get lost if you don't enable the leds.
> >
> > A better policy is: "NEVER USE SELECT".
> >
>
> No, this is BS. User selecting, for example, a button driver should not
> care that it is working in polling mode only and needs polled device
> library to work. As it was said before, drivers need to depend on major
> subsystems and select minors and library modules.

I dislike select, but reality is that modules do need to select/enable
library code and minor features sometimes.

OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
to enable an entire subsystem is wrong and bad IMO.

> The fact that our Kconfig can't really provide us with the functionality
> we desire (be it because the logic is fuzzy and hard to formalize or
> some other reason) shoud not force "NO SELECT" policy, we just need to
> be careful when using it.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

2010-12-08 22:20:21

by Thadeu Lima de Souza Cascardo

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 08, 2010 at 01:51:05PM -0800, Randy Dunlap wrote:
> On Wed, 8 Dec 2010 09:46:04 -0800 Dmitry Torokhov wrote:
>
> > On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote:
> > > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote:
> > > >
> > > > I don't really see how it's a recursive dependency, but maybe it's
> > > > time to clean this KConfig.
> > > > What is our current policy about that ?
> > > >
> > > > I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> > > > and select obscure things so
> > > > that the driver does not get lost if you don't enable the leds.
> > >
> > > A better policy is: "NEVER USE SELECT".
> > >
> >
> > No, this is BS. User selecting, for example, a button driver should not
> > care that it is working in polling mode only and needs polled device
> > library to work. As it was said before, drivers need to depend on major
> > subsystems and select minors and library modules.
>
> I dislike select, but reality is that modules do need to select/enable
> library code and minor features sometimes.
>
> OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
> to enable an entire subsystem is wrong and bad IMO.

I am 50/50 here. On one hand selecting whole subsystems may not be the
best option, on the other hand (depending on how Kconfig is organized)
it might make sense. Consider you have an USB joystick. You are in
input, in joystick sub-menu, which comes _before_ USB. If you happen to
have USB disabled then you, with your scheme, will not see the entry for
the joystick. You will have to go into USB menu, activate USB and then
go back and scan menus that you already been to for any new options. And
again, and again. Not very friendly and so right now USB input devices
do depend on INPUT, select USB and depend on USB_ARCH_HAS_HCD (to make
sure USB can be activated).

Also, in case of CMPC, the user wants to support _all_ features of
his/her laptop which is kind of useless without input, right?

--
Dmitry

2010-12-08 22:38:58

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 08, 2010 at 02:12:17PM -0800, Dmitry Torokhov wrote:
> On Wed, Dec 08, 2010 at 01:51:05PM -0800, Randy Dunlap wrote:
> > On Wed, 8 Dec 2010 09:46:04 -0800 Dmitry Torokhov wrote:
> >
> > > On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote:
> > > > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote:
> > > > >
> > > > > I don't really see how it's a recursive dependency, but maybe it's
> > > > > time to clean this KConfig.
> > > > > What is our current policy about that ?
> > > > >
> > > > > I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> > > > > and select obscure things so
> > > > > that the driver does not get lost if you don't enable the leds.
> > > >
> > > > A better policy is: "NEVER USE SELECT".
> > > >
> > >
> > > No, this is BS. User selecting, for example, a button driver should not
> > > care that it is working in polling mode only and needs polled device
> > > library to work. As it was said before, drivers need to depend on major
> > > subsystems and select minors and library modules.
> >
> > I dislike select, but reality is that modules do need to select/enable
> > library code and minor features sometimes.
> >
> > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
> > to enable an entire subsystem is wrong and bad IMO.
>
> I am 50/50 here. On one hand selecting whole subsystems may not be the
> best option, on the other hand (depending on how Kconfig is organized)
> it might make sense. Consider you have an USB joystick. You are in
> input, in joystick sub-menu, which comes _before_ USB. If you happen to
> have USB disabled then you, with your scheme, will not see the entry for
> the joystick. You will have to go into USB menu, activate USB and then
> go back and scan menus that you already been to for any new options. And
> again, and again. Not very friendly and so right now USB input devices
> do depend on INPUT, select USB and depend on USB_ARCH_HAS_HCD (to make
> sure USB can be activated).
>
> Also, in case of CMPC, the user wants to support _all_ features of
> his/her laptop which is kind of useless without input, right?

Thanks, Dmitry, for building the case for CMPC. Besides input devices,
classmate-laptop only supports a single rfkill device. Currently, using
the driver without rfkill support is possible. That's not the case when
the input subsystem is disabled. I would like the user to go the the
platform/x86 menu and say 'hey, classmate support'.

That would however, be an argument for using select for everything, or
making depends work just like some dependencies resolvers work in
package management systems, like apt. OTOH, that would imply in lots of
undesired questions when someone does not want to enable anything that
depends on USB (or any bus or subsystem) at all.

For the case of CMPC, the user has already entered the platform/x86
menu. The CMPC option will not be visible if INPUT has been disabled.
And select works just fine here, since INPUT does not depend on
anything. OTOH, INPUT can only be disabled if EMBEDDED is enabled. And
if the user has done that, user must know what user is doing. So, if the
rule of thumb is that major subsystems should not be selected, I'd be
willing to submit of ack a patch fixing that.

Regards,
Cascardo.

Attachments:

(No filename) (3.23 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2010-12-08 23:08:48

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote:
>
> I dislike select, but reality is that modules do need to select/enable
> library code and minor features sometimes.
>
> OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
> to enable an entire subsystem is wrong and bad IMO.

This is just a deficiency in the tools. The correct answer is to fix the
damn tools, not invent this silly 'select' facility which means much the
same thing as 'depends on' but is implemented differently.

As long ago as the mid-1990s, the Nemesis research OS was using a tcl
xconfig tool based on the Linux one, but which would show you the
dependencies for an option that was disabled, so you could enable them
where you needed to. Rather than just hiding the option completely.

--
dwmw2

2010-12-08 23:31:12

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 08, 2010 at 11:08:39PM +0000, David Woodhouse wrote:
> On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote:
> >
> > I dislike select, but reality is that modules do need to select/enable
> > library code and minor features sometimes.
> >
> > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
> > to enable an entire subsystem is wrong and bad IMO.
>
> This is just a deficiency in the tools. The correct answer is to fix the
> damn tools, not invent this silly 'select' facility which means much the
> same thing as 'depends on' but is implemented differently.
>
> As long ago as the mid-1990s, the Nemesis research OS was using a tcl
> xconfig tool based on the Linux one, but which would show you the
> dependencies for an option that was disabled, so you could enable them
> where you needed to. Rather than just hiding the option completely.

Even better tool would allow selecting the needed optios right there,
without the need of moving away from teh current option. And yet better
tool would not even ask user and enable them on its own. Hey, but we
have it! It's called "select".

Seriously, select is dangerous. I wonder if a rule like "One can only
select a symbol whose dependencies are all satisfied by the current
symbol and/or its parents and the symbols they select or depend on"
would not make select safe enough.

--
Dmitry

2010-12-08 23:35:16

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, 2010-12-08 at 15:31 -0800, Dmitry Torokhov wrote:
> Even better tool would allow selecting the needed optios right there,
> without the need of moving away from teh current option.

That's exactly what the Nemesis version of xconfig did, almost 15 years
ago.

> And yet better tool would not even ask user and enable them on its
> own. Hey, but we have it! It's called "select".

The tools could do that with 'depends on' too. Why make a distinction?

> Seriously, select is dangerous. I wonder if a rule like "One can only
> select a symbol whose dependencies are all satisfied by the current
> symbol and/or its parents and the symbols they select or depend on"
> would not make select safe enough.

"One can only select a symbol which isn't otherwise presented to the
user as a choice".

So things like CONFIG_REED_SOLOMON are fine to be selected, because the
user would never see it anyway.

Otherwise, just use depends. And if that's a problem for you, fix the
damn tools.

--
dwmw2

2010-12-08 23:41:24

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, 2010-12-08 at 15:34 -0800, Randy Dunlap wrote:
> xconfig has options that show all symbols. I use that most of the time,
> but I bet that most people do not.

That just means that 'select' is *completely* pointless and stupid,
rather than being a lazy workaround for broken tools.

Time to remove it *entirely*, perhaps?

--
dwmw2

2010-12-08 23:35:56

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, 08 Dec 2010 23:08:39 +0000 David Woodhouse wrote:

> On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote:
> >
> > I dislike select, but reality is that modules do need to select/enable
> > library code and minor features sometimes.
> >
> > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
> > to enable an entire subsystem is wrong and bad IMO.
>
> This is just a deficiency in the tools. The correct answer is to fix the
> damn tools, not invent this silly 'select' facility which means much the
> same thing as 'depends on' but is implemented differently.
>
> As long ago as the mid-1990s, the Nemesis research OS was using a tcl
> xconfig tool based on the Linux one, but which would show you the
> dependencies for an option that was disabled, so you could enable them
> where you needed to. Rather than just hiding the option completely.

xconfig has options that show all symbols. I use that most of the time,
but I bet that most people do not.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

2010-12-08 23:50:03

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 08, 2010 at 11:35:08PM +0000, David Woodhouse wrote:
> On Wed, 2010-12-08 at 15:31 -0800, Dmitry Torokhov wrote:
> > Even better tool would allow selecting the needed optios right there,
> > without the need of moving away from teh current option.
>
> That's exactly what the Nemesis version of xconfig did, almost 15 years
> ago.
>
> > And yet better tool would not even ask user and enable them on its
> > own. Hey, but we have it! It's called "select".
>
> The tools could do that with 'depends on' too. Why make a distinction?

To allow automatic/manual selection. Sometimes the only answer to
"shoudl it be enabled" is "Yes". I.e. drivers that need polling need
input-polldev support. There is no reason whatsoever to even ask user.

Same thing for platform drivers. "Don't you also want to enable option for
your keyboard and mouse to work? Go do that, you won't regret." "Well,
duh!"

>
> > Seriously, select is dangerous. I wonder if a rule like "One can only
> > select a symbol whose dependencies are all satisfied by the current
> > symbol and/or its parents and the symbols they select or depend on"
> > would not make select safe enough.
>
> "One can only select a symbol which isn't otherwise presented to the
> user as a choice".

Input-polldev _is_ presented as a choice in case user or distro want to
use out of tree driver that depends on it. Does this mean we shoudl
disallow selects on it? I don't think so.

> So things like CONFIG_REED_SOLOMON are fine to be selected, because the
> user would never see it anyway.
>
> Otherwise, just use depends. And if that's a problem for you, fix the
> damn tools.

Yep, starting with kconfig.

--
Dmitry

2010-12-08 23:52:27

[permalink] [raw]

Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

On Wed, Dec 08, 2010 at 03:34:28PM -0800, Randy Dunlap wrote:
> On Wed, 08 Dec 2010 23:08:39 +0000 David Woodhouse wrote:
>
> > On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote:
> > >
> > > I dislike select, but reality is that modules do need to select/enable
> > > library code and minor features sometimes.
> > >
> > > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
> > > to enable an entire subsystem is wrong and bad IMO.
> >
> > This is just a deficiency in the tools. The correct answer is to fix the
> > damn tools, not invent this silly 'select' facility which means much the
> > same thing as 'depends on' but is implemented differently.
> >
> > As long ago as the mid-1990s, the Nemesis research OS was using a tcl
> > xconfig tool based on the Linux one, but which would show you the
> > dependencies for an option that was disabled, so you could enable them
> > where you needed to. Rather than just hiding the option completely.
>
>
> xconfig has options that show all symbols. I use that most of the time,
> but I bet that most people do not.
>

GUI tools have means of presenting this, menuconfig and oldconfig have
harder time...

--
Dmitry

2010-12-09 00:35:27