From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29639C34050 for ; Wed, 19 Feb 2020 08:42:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 045D12465D for ; Wed, 19 Feb 2020 08:42:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727561AbgBSIm1 (ORCPT ); Wed, 19 Feb 2020 03:42:27 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:38480 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727513AbgBSImY (ORCPT ); Wed, 19 Feb 2020 03:42:24 -0500 Received: by mail-oi1-f194.google.com with SMTP id r137so3474135oie.5; Wed, 19 Feb 2020 00:42:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gcGrTtSZqo75NtjJJ7mVC6SXcJFXr8kJ31jQXw/H/KQ=; b=NyWvCZmb/ZhQuWuhTB6KcDNc6/NifMcxvCzFi0KeeNpo0KBdzXEhQNeRpwWFBTW+SC rr/KEcuzwVkx+DZroLcnUPZlftpDYzmEwoyLK7Ci8+auP4LXhAYfJdivbjnL54fj+ylx MYbzSc9FhXx+Ud98tw3fVOEoOs/0otB0ClAD4e72BBj8GT12tW1OQfaaLmV3wXsYMKOX l0PGGeKwEYZX+jTqbZI1X58F6KWkGHOH8fYbUn5dXUXK/BcNIni9sn+wHVC6wXXfDQ9A 3ESbxREPl1rg2EZoYspUTbzaixSlXtTVrG8xzptprJxz67x92Fmc8chfJwvvpLFlCch7 XlrQ== X-Gm-Message-State: APjAAAW6V1G0Jt5ZOJT8M5ZhB+SAfegdtKIjFlzxZg6TB18GYS9szwYW O6t3gkH94OzOBRCIzt1oahXAURv6gHNI8JWkJ0knDkV4 X-Google-Smtp-Source: APXvYqwXN+JTU40xx/WiTO9R063gRnVxxMUOM08YTvRovwTavoMCLPf3oKtDrBoe6c7DGxqkQRQZoNf+fGvgE1SDjlw= X-Received: by 2002:aca:1a06:: with SMTP id a6mr3748069oia.148.1582101742559; Wed, 19 Feb 2020 00:42:22 -0800 (PST) MIME-Version: 1.0 References: <20200219074950.23344-1-masahiroy@kernel.org> In-Reply-To: <20200219074950.23344-1-masahiroy@kernel.org> From: Geert Uytterhoeven Date: Wed, 19 Feb 2020 09:42:10 +0100 Message-ID: Subject: Re: [PATCH] kconfig: make 'imply' obey the direct dependency To: Masahiro Yamada Cc: linux-kbuild , Arnd Bergmann , Nicolas Pitre , Richard Cochran , Thomas Gleixner , John Stultz , Josh Triplett , Mark Brown , Ulf Magnusson , Jonathan Corbet , Michal Marek , "open list:DOCUMENTATION" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Hi Yamada-san, On Wed, Feb 19, 2020 at 8:51 AM Masahiro Yamada wrote: > The 'imply' statement may create unmet direct dependency when the > implied symbol depends on m. > > [Test Code] > > config FOO > tristate "foo" > imply BAZ > > config BAZ > tristate "baz" > depends on BAR > > config BAR > def_tristate m > > config MODULES > def_bool y > option modules > > If you set FOO=y, BAZ is also promoted to y, which results in the > following .config file: > > CONFIG_FOO=y > CONFIG_BAZ=y > CONFIG_BAR=m > CONFIG_MODULES=y > > This ignores the dependency "BAZ depends on BAR". > > Unlike 'select', what is worse, Kconfig never shows the > "WARNING: unmet direct dependencies detected for ..." for this case. > > Because 'imply' should be weaker than 'depends on', Kconfig should > take the direct dependency into account. > > Describe this case in Documentation/kbuild/kconfig-language.rst for > clarification. > > Commit 237e3ad0f195 ("Kconfig: Introduce the "imply" keyword") says that > a symbol implied by y is restricted to y or n, excluding m. > > As for the combination of FOO=y and BAR=m, the case of BAZ=m is excluded > by the 'imply', and BAZ=y is also excluded by 'depends on'. So, only the > possible value is BAZ=n. > > Having said that, this case was probably "We don't care" at that time > because Kconfig did not handle 'depends on m' correctly until > commit f622f8279581 ("kconfig: warn unmet direct dependency of tristate > symbols selected by y") fixed it. > > Backporting this to 4.19+ will probably be fine. If you care this > problem on 4.14.x, you need to backport f622f8279581 as well. > > Signed-off-by: Masahiro Yamada Thanks a lot! This fixes the build issues in https://lore.kernel.org/alsa-devel/CAMuHMdW8SvDgQJyenTtEm4Xn2Ma6PK9pfwKR2_gn60t2AqNWXg@mail.gmail.com/ Tested-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds