Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1027456ybb; Wed, 8 Apr 2020 14:59:32 -0700 (PDT) X-Google-Smtp-Source: APiQypLVhQGjjH0p2kXpJUDSP4bkwMSHunGVrxG9suR29FKuwy14tiPZvEAvSXIZEy5wH5HZlzdt X-Received: by 2002:a9d:544:: with SMTP id 62mr7446771otw.355.1586383171436; Wed, 08 Apr 2020 14:59:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586383171; cv=none; d=google.com; s=arc-20160816; b=HwK+P+yMHa95/eNH7Fj5WeyqN72bMI4ZNQOxTGOxHFsxULWAs5SfkpDVBmc/jUgcur l52Vu+toCMytlH6+FD24q0gMpt2QLBJcj5D3Lf91F8yEGhpkb0azpPSju1hCm1V8FE7R f+0Mh5dBkEKxcky3CMJFCaORhicxsTEZNY9GFczKyhKfyFdIV+tli+SGRcW8ZvH1urA0 SlqF6quTbhzWgxdyLU4PX0k2ps4s3R+ASsz1axatoZqHfe0ffj10BGUL5ZEvakZl15gf K6y4siaea6CzLeGBC5muuu4AE9vnm3Tq75Wr+6I3GO1JW9gMy8cY0IJa6Crm1V600/1C XnGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=9elDXQ2K7X+oKhQQTeS1VtE0YLCxujz0RpbQZB76zFs=; b=Ot7sj67Fkz0OY4jq2ejgFvf/a+qkaibvnAgzWWzt99vKBDvcfZsVC3eTQvcZjtZ/kF 4zt5mC7NgcAy+lGYC1p70Sc+MFFnADlPhnpufd/svJR+WmSF8pN/Sg2JfyW2aGRNs0DS oXV5JJHcA9vfUEcX3U15VREF9Z4wP8IIKlVAAOuI37EYEKhN8pBfmXOLKpVflbsoKn5Q nzmWSCmNtvmOvGW3xXJhYmBCTKcU5ctmGV6yJALwmLysSVfSV9p+gWCm+A5mOoCm1wLc y1+VWQ3lOURk5HDGxQRjusUPNwyLi0X0ChyyZdAouKWX8qXDemfYprGUWi2//p8GdWvG m3bA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pobox.com header.s=sasl header.b=AcgYlXTn; dkim=temperror (no key for signature) header.i=@fluxnic.net header.s=2016-12.pbsmtp header.b=rhI9Y9k7; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h145si2488195oib.210.2020.04.08.14.59.19; Wed, 08 Apr 2020 14:59:31 -0700 (PDT) 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=@pobox.com header.s=sasl header.b=AcgYlXTn; dkim=temperror (no key for signature) header.i=@fluxnic.net header.s=2016-12.pbsmtp header.b=rhI9Y9k7; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729339AbgDHVRy (ORCPT + 99 others); Wed, 8 Apr 2020 17:17:54 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:51922 "EHLO pb-smtp2.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726663AbgDHVRx (ORCPT ); Wed, 8 Apr 2020 17:17:53 -0400 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 15C175069A; Wed, 8 Apr 2020 17:17:49 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=sasl; bh=UIkb5A+H+jKDQ3GWp3Tbf0a8oXM=; b=AcgYlX TnCHG5UcWgHkl8IlsC1e1uSPmTDBMpHTb4rnXL06C201X87TtsWkywbE7tyhVEgL joaA4hStDMXuw8ZUssiqUmef7sB8CpImWNNVRynUk532oaFQQiq7ylZfjC6WKOG0 n438CvV7eUlVobxBSL2o/win8JdgiYwNnjPJU= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EBD9250698; Wed, 8 Apr 2020 17:17:48 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type; s=2016-12.pbsmtp; bh=C5qZnucLOvddU0/aYHUwvuoSJMokDJ9d4K7zprmELhs=; b=rhI9Y9k7ariW+D63u1TPx511dXcnGqLfZWvC4hyySB7C8iu6lcGWtATA4lzrxivdp5SOwycFxqeXwlBHGMIZ+/TN4juy0TA9A3TTPQBm6TTbluFOmyrcr3+B1c5KEDP/2UtjGbuSvcOZxVxL1iYp3mQwA1ofghE5W48Ncw1e8cc= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 5F86F50697; Wed, 8 Apr 2020 17:17:48 -0400 (EDT) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 798F72DA0D4B; Wed, 8 Apr 2020 17:17:47 -0400 (EDT) Date: Wed, 8 Apr 2020 17:17:47 -0400 (EDT) From: Nicolas Pitre To: Arnd Bergmann cc: "linux-kernel@vger.kernel.org" , Masahiro Yamada , Andrzej Hajda , Neil Armstrong , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , Kieran Bingham , "David S. Miller" , Saeed Mahameed , Leon Romanovsky , dri-devel , Linux-Renesas , Networking , linux-rdma Subject: Re: [RFC 0/6] Regressions for "imply" behavior change In-Reply-To: Message-ID: References: <20200408202711.1198966-1-arnd@arndb.de> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Pobox-Relay-ID: 65B28AAA-79DE-11EA-BF5C-D1361DBA3BAF-78420484!pb-smtp2.pobox.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Apr 2020, Arnd Bergmann wrote: > On Wed, Apr 8, 2020 at 10:38 PM Nicolas Pitre wrote: > > On Wed, 8 Apr 2020, Arnd Bergmann wrote: > > > I have created workarounds for the Kconfig files, which now stop using > > > imply and do something else in each case. I don't know whether there was > > > a bug in the kconfig changes that has led to allowing configurations that > > > were not meant to be legal even with the new semantics, or if the Kconfig > > > files have simply become incorrect now and the tool works as expected. > > > > In most cases it is the code that has to be fixed. It typically does: > > > > if (IS_ENABLED(CONFIG_FOO)) > > foo_init(); > > > > Where it should rather do: > > > > if (IS_REACHABLE(CONFIG_FOO)) > > foo_init(); > > > > A couple of such patches have been produced and queued in their > > respective trees already. > > I try to use IS_REACHABLE() only as a last resort, as it tends to > confuse users when a subsystem is built as a module and already > loaded but something relying on that subsystem does not use it. Then this is a usage policy issue, not a code correctness issue. The correctness issue is fixed with IS_REACHABLE(). If you want to enforce a usage policy then this goes in Kconfig. But you still can do both. Nicolas