Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp380961ybv; Wed, 19 Feb 2020 01:24:56 -0800 (PST) X-Google-Smtp-Source: APXvYqxgfqRz6dY2TBvaPUpbGr9sMZ0LjzN0R4zKd8uEhWKMRiYfnIZ9D73ZUZH3TdjPsuxC3lhy X-Received: by 2002:a05:6808:350:: with SMTP id j16mr3853127oie.168.1582104296817; Wed, 19 Feb 2020 01:24:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582104296; cv=none; d=google.com; s=arc-20160816; b=br3/9YnoZb1n/99g/5PVOsoBQBBCDwsCwZ8sMe388EtpVIWoOHV06WGTJPXsxi/UcJ NeoiWHp+R1413dB4xSwn5HQ80psbrmyyBLwd4J0aXJlBx0pcss06Al2yZq19YdSWOIqz /fN9G1tSAQLDKLKgRT31ibVcx87IrQsOusnjZE+305xf5y2CrcSVvZEAc3lEl6h5kVEi O+ZmQnXCy/gKwOH6b+v7YWl4tLSNm6CjUIUX51W/DokbRZUuxxWYX70/M0ICMx01cCec O3auEfVHOv9DpHzgYEp1rgm65O7WU31Ipi+mpGPtA9yYDz4qRMRBzuaYUkE+z2W5LwBL +h7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=DF+/evkLClqtfnRvGjBml/csN+45+NlnkxxMv7DJLo8=; b=idyCZmzk/sJCM/euhBgmW51ZdapgFI4xfBXzzv2vr1/Ofhq4haCeYt/B7d7MW+qRnl TQqEjN89qkpLEDmGm519cumo7iyt5H0Flt77lonajF3ToHqikggyZs2AC2+4WOlzC+I0 Ia/PGZpAh/K0SHTLCykb+XFoq72JqK3zJQDKzLMK0p5i4BuMFBr/tR7Pqp6dH4vh08t2 cqkswPdT+a9Z2gnecaIT4iIWGy1s1X37hmtcXcPKhHFrYRlJ1Jr8A1kPrtDZUlnX8x5Y l/JKrNwPfC/0ToSIoMmbGqZ6fq8e3pXBGdirKTGT7T7Ezm/IB8w/CjlC3l38WSrd64lX MsKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=UyoUnKbo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v9si8795497oie.22.2020.02.19.01.24.44; Wed, 19 Feb 2020 01:24:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=UyoUnKbo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726622AbgBSJYh (ORCPT + 99 others); Wed, 19 Feb 2020 04:24:37 -0500 Received: from conssluserg-05.nifty.com ([210.131.2.90]:32638 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726297AbgBSJYh (ORCPT ); Wed, 19 Feb 2020 04:24:37 -0500 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (authenticated) by conssluserg-05.nifty.com with ESMTP id 01J9ODcc024014; Wed, 19 Feb 2020 18:24:14 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com 01J9ODcc024014 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1582104254; bh=DF+/evkLClqtfnRvGjBml/csN+45+NlnkxxMv7DJLo8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UyoUnKbo+w6EdQGG5oAobMsEyzSwFO61oBEYLdBUsXnUXVaaEEuWhWnpzWI7QSi7l 1qWbTufAyZqG9nWVta90KSitwnNwPYCksFaKQGrFsEvkdmhsGlYQWPkuV3xKXNM9lg csC6/h1FBEdt3tepDh5L5GIOret/no3ZJn/SP9RpFxP2YfTCJN/5W8f+ZW+fluzQ/a awepQt4yyAaD4oILvhWNT2rXTX+DI/VU1zCEUA0OgfPl4HD+WFNTKDITkGzRYguFD4 azVXqFIrhopIHTFzr9/ix7g4CvWYEERLIRAPEAQLE3nhUo9Nzt/5udMTrKdnPj69uV WAPbJjjs1ByBw== X-Nifty-SrcIP: [209.85.217.54] Received: by mail-vs1-f54.google.com with SMTP id r18so14969537vso.5; Wed, 19 Feb 2020 01:24:14 -0800 (PST) X-Gm-Message-State: APjAAAW0DEJ395PVAQo9sNgPHjgvFONImvq63fGM5g/4NIwvi8+WJmRT w7dxyLgVigTM1SqcLJsisYLCtzSOZz1/2PE5Bj4= X-Received: by 2002:a67:6485:: with SMTP id y127mr14029090vsb.54.1582104252914; Wed, 19 Feb 2020 01:24:12 -0800 (PST) MIME-Version: 1.0 References: <20200219074950.23344-1-masahiroy@kernel.org> In-Reply-To: From: Masahiro Yamada Date: Wed, 19 Feb 2020 18:23:37 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kconfig: make 'imply' obey the direct dependency To: Geert Uytterhoeven 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 19, 2020 at 5:42 PM Geert Uytterhoeven wrote: > > 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 > Even if this patch fixes the build issues, the result may not be what you expect. The very subtle part of 'imply' is that symbols implied by 'y' cannot be 'm'. When CONFIG_SND_SOC_ALL_CODECS=y, the select'ed drivers were previously able to be 'm'. After ea00d95200d02, drivers that were previously 'm' are now 'n'. Probably, it shrunk the test-coverage. I'd recommend to compare the .config file. -- Best Regards Masahiro Yamada