Received: by 10.223.176.5 with SMTP id f5csp1386129wra; Wed, 7 Feb 2018 18:47:57 -0800 (PST) X-Google-Smtp-Source: AH8x2251MXUOAMXeIPfm9UuznH5jTe61e8p5fsf5/3AZqn0zoW5NOZQ1tqke7XgXe1WcZnoJCf6D X-Received: by 2002:a17:902:9686:: with SMTP id n6-v6mr7953824plp.333.1518058076991; Wed, 07 Feb 2018 18:47:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518058076; cv=none; d=google.com; s=arc-20160816; b=t1agoagRvhnJFheXJyS2ibsirv91M8LP8XdwGLLrY1QIfPNV/hTx6enWh9731/k1+h KmCzubpFh3X2AJa1gDFIaJpRe4BPoCCNl+S26pcaWC67ETUgLAKSP+YvUaXCECeSdqom PyGTwz0N7lCTUynQgtc6iDChdEmtqZK8v6B+d3cuyzyOPqCidlugRdzCyzEzE2BLPFAT mhufjyHzRsRYKcDf3YqtyOhd1gF88eE8Gx7hBS8J21Wx2e9RBJ+oxNB+PNMynCb76/4r Ga4TgD3i1UqsmSz3CXzis8oot9QAvKJNMCYryZZVp1SUSVpX0/DBWNj42rKr2InRZJK+ 1vAA== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=wEDL8scbk8654cxP8a4pALvz4bGdMjpS24+8qjEbKV0=; b=RSaAzkFQLVsJbpu3Ha/PoFIj0X0fP8dMd6zEf+fw9ra9qGnghXP79fkWYCMSGLcQzH XScre+YfxS0LHf/dqtTSpKwXXMV7RtCSLhtc0eBbRd3OhXcwntjM8zB+l8w8AHsgN4co e/j/352u1KnVu/LNlEJKb2yTv+fje6hnZOT5xfMZACN7UqSX8RqTNZDfwgY/odFvzmFF WWUkUhpdOSmYP68eHtVl8dStq3M8VIltMe+m6PQvLbM8V9Rm37pONWxXW60x9/PiomRN z9DtzgJ/BDg02p9crgtXdIk73Db0wamMMckecpKWmbTV94CuOy2RicgD9II0DhSxaZ0A q7RA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hIW3/5FM; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f184si1754432pgc.696.2018.02.07.18.47.43; Wed, 07 Feb 2018 18:47: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=@gmail.com header.s=20161025 header.b=hIW3/5FM; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752016AbeBHCrD (ORCPT + 99 others); Wed, 7 Feb 2018 21:47:03 -0500 Received: from mail-vk0-f68.google.com ([209.85.213.68]:33679 "EHLO mail-vk0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751848AbeBHCrA (ORCPT ); Wed, 7 Feb 2018 21:47:00 -0500 Received: by mail-vk0-f68.google.com with SMTP id w201so1899639vkw.0; Wed, 07 Feb 2018 18:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wEDL8scbk8654cxP8a4pALvz4bGdMjpS24+8qjEbKV0=; b=hIW3/5FMXT668SGfh6S+yKAoaj1npMJYoqd2DUZ825ci1iF5upZvsoTz6o2UuNQyGm FXFbugdMKZop2lDsoICcRcoqDOkFzAH5ikgsJeMaHEsn/WFGkyGjeV1E0jg78s51VBFS FqeBpg16gwLUgQg9AWaRM6XFr7+1k5HdxilXbBSzjbaai7B3CIHBJNNDphB0d9f1MKNK tLXNj4Art2VC62SkjOTjk3E8brUV0tP29rP4CXlWB4VIk6vUKhNkFz9DfM0TDoccCPCM wokyto5N9F7pql/xtEG1Bec2ZIK7x/ijI4pIa3t4QzyUCLBvLT/T4x82u64Vf/wtMFLO S7Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wEDL8scbk8654cxP8a4pALvz4bGdMjpS24+8qjEbKV0=; b=udSWNSgSWGdQygvr7izGUZF3wugb186eswySqv4KztJkIZHMwdsq10P44ZBh/ugxNR P8iZF1rTjshwAt+1DmuIlxkkQ2ptfXu/S/chb2l7l4CyBizC2ybD4Xjx6I5Vf71aaojX aNuacXcCZgR1o4XktpqQrg2REHwVOAZin9Ii8QcoEeFrxjxC/VCptgzgwFseNgKftdhy P0HuC4M0C2QXf/uE+TxGFnolUW9xaASDd1CnUcWhdXYscXOQ5m/NDDvokFmcaflEMlCt uf7GEHxCGmRApZEfBy9kn/T7Kxhz9jukQTq9dRbfMLNwgQOWMBiz/MxOyoGkGErIYnh+ 34xA== X-Gm-Message-State: APf1xPBCYcSoFZFnkVhwmiBiOhRJUdczRGB17NMHdtTHlIoVTEe+7+ku OqG491EWesxeuUzGnOrfG5w2+XB12dMh5U+UDYU= X-Received: by 10.31.15.149 with SMTP id 143mr6712498vkp.126.1518058019357; Wed, 07 Feb 2018 18:46:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.70.21 with HTTP; Wed, 7 Feb 2018 18:46:59 -0800 (PST) In-Reply-To: References: <1517877294-4826-1-git-send-email-yamada.masahiro@socionext.com> <1517877294-4826-3-git-send-email-yamada.masahiro@socionext.com> <20180207225551.imdp6gqbdwzyvhwm@huvuddator> From: Ulf Magnusson Date: Thu, 8 Feb 2018 03:46:59 +0100 Message-ID: Subject: Re: [PATCH 02/14] kconfig: do not write choice values when their dependency becomes n To: Masahiro Yamada Cc: Linux Kbuild mailing list , Greg Kroah-Hartman , Andrew Morton , Nicolas Pitre , "Luis R . Rodriguez" , Randy Dunlap , Sam Ravnborg , Michal Marek , Linus Torvalds , "Luis R. Rodriguez" , Linux Kernel Mailing List , Heinrich Schuchardt 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 Thu, Feb 8, 2018 at 3:42 AM, Masahiro Yamada wrote: > 2018-02-08 7:55 GMT+09:00 Ulf Magnusson : >> On Tue, Feb 06, 2018 at 09:34:42AM +0900, Masahiro Yamada wrote: >>> "# CONFIG_... is not set" for choice values are wrongly written into >>> the .config file if they are once visible, then become invisible later. >>> >>> Test case >>> --------- >>> >>> ---------------------------(Kconfig)---------------------------- >>> config A >>> bool "A" >>> >>> choice >>> prompt "Choice ?" >>> depends on A >>> >>> config CHOICE_B >>> bool "Choice B" >>> >>> config CHOICE_C >>> bool "Choice C" >>> >>> endchoice >>> ---------------------------------------------------------------- >>> >>> ---------------------------(.config)---------------------------- >>> CONFIG_A=y >>> ---------------------------------------------------------------- >>> >>> With the Kconfig and .config above, >>> >>> $ make config >>> scripts/kconfig/conf --oldaskconfig Kconfig >>> * >>> * Linux Kernel Configuration >>> * >>> A (A) [Y/n] n >>> # >>> # configuration written to .config >>> # >>> $ cat .config >>> # >>> # Automatically generated file; DO NOT EDIT. >>> # Linux Kernel Configuration >>> # >>> # CONFIG_A is not set >>> # CONFIG_CHOICE_B is not set >>> # CONFIG_CHOICE_C is not set >>> >>> Here, >>> >>> # CONFIG_CHOICE_B is not set >>> # CONFIG_CHOICE_C is not set >>> >>> should not be written into the .config file because their dependency >>> "depends on A" is unmet. >>> >>> Currently, there is no code that clears SYMBOL_WRITE of choice values. >>> >>> Clear SYMBOL_WRITE for all symbols in sym_calc_value(), then set it >>> again after calculating visibility. >>> >>> Signed-off-by: Masahiro Yamada >>> --- >> >>> scripts/kconfig/symbol.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c >>> index c9123ed..5d6f6b1 100644 >>> --- a/scripts/kconfig/symbol.c >>> +++ b/scripts/kconfig/symbol.c >>> @@ -371,8 +371,7 @@ void sym_calc_value(struct symbol *sym) >>> sym->curr.tri = no; >>> return; >>> } >>> - if (!sym_is_choice_value(sym)) >>> - sym->flags &= ~SYMBOL_WRITE; >>> + sym->flags &= ~SYMBOL_WRITE; >>> >>> sym_calc_visibility(sym); >>> >>> @@ -385,6 +384,7 @@ void sym_calc_value(struct symbol *sym) >>> if (sym_is_choice_value(sym) && sym->visible == yes) { >>> prop = sym_get_choice_prop(sym); >>> newval.tri = (prop_get_symbol(prop)->curr.val == sym) ? yes : no; >>> + sym->flags |= SYMBOL_WRITE; >>> } else { >>> if (sym->visible != no) { >>> /* if the symbol is visible use the user value >>> -- >>> 2.7.4 >>> >> >> Reviewed-by: Ulf Magnusson >> >> There's a possible simplification here: >> >> All defined symbols, regardless of type, and regardless of whether >> they're choice value symbols or not, always get written out if they have >> non-n visibility. Therefore, the sym->visible != no check for >> SYMBOL_WRITE can be moved to before the symbol type check, which gets >> rid of two SYMBOL_WRITE assignments and makes it clear that the logic is >> the same for all paths. >> >> This is safe for symbols defined without a type (S_UNKNOWN) too, because >> conf_write() skips those (plus they already generate a warning). >> >> This matches how I do it in the tri_value() function in Kconfiglib: >> https://github.com/ulfalizer/Kconfiglib/blob/master/kconfiglib.py#L2574. >> SYMBOL_WRITE corresponds to _write_to_conf. >> >> I've included a patch below. I tested it with the Kconfiglib test suite, >> which verifies that the C implementation still generates the same >> .config file for all defconfig files as well as for >> all{no,yes,def}config, for all ARCHes. >> >> (The Kconfiglib test suite runs scripts/kconfig/conf and compares its >> output against it, which means it doubles as a regression test for the C >> tools.) > > Thank you for this. This is simpler, and please let me take it. > Could just mod the existing patch. Saves the hassle of creating a new one. :) > I confirmed the same results were produced. > > -- > Best Regards > Masahiro Yamada Cheers, Ulf