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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 0C3BAC2BB85 for ; Thu, 16 Apr 2020 10:17:49 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D9AC4206B9 for ; Thu, 16 Apr 2020 10:17:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9AC4206B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 32DDC6E2DF; Thu, 16 Apr 2020 10:17:48 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7DF336E2DD for ; Thu, 16 Apr 2020 10:17:46 +0000 (UTC) IronPort-SDR: UWVF6zZlxDMUH5gLQo8n4O/qWPtwQvlOqLKQrzYWfRU6MxAj/xLqRmvioVMFNLZbX4ZUHdv8DR fLqT8EwzT1GQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2020 03:17:42 -0700 IronPort-SDR: PabvyhK/GDPyBjaf0paWWd5oAAbGpqHHyicWhdVU0osJ1cJkrEV/y2jitUhatIDlUFj03yE+KQ +MY52IYzL9ng== X-IronPort-AV: E=Sophos;i="5.72,390,1580803200"; d="scan'208";a="400622555" Received: from ellenfax-mobl2.ger.corp.intel.com (HELO localhost) ([10.249.44.122]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2020 03:17:34 -0700 From: Jani Nikula To: Arnd Bergmann , Saeed Mahameed Subject: Re: [RFC 0/6] Regressions for "imply" behavior change In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200408202711.1198966-1-arnd@arndb.de> <20200408224224.GD11886@ziepe.ca> <87k12pgifv.fsf@intel.com> <7d9410a4b7d0ef975f7cbd8f0b6762df114df539.camel@mellanox.com> <20200410171320.GN11886@ziepe.ca> <16441479b793077cdef9658f35773739038c39dc.camel@mellanox.com> <20200414132900.GD5100@ziepe.ca> <20200414152312.GF5100@ziepe.ca> <834c7606743424c64951dd2193ca15e29799bf18.camel@mellanox.com> Date: Thu, 16 Apr 2020 13:17:32 +0300 Message-ID: <874ktj4tvn.fsf@intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "airlied@linux.ie" , "jernej.skrabec@siol.net" , "leon@kernel.org" , "narmstrong@baylibre.com" , "linux-rdma@vger.kernel.org" , "netdev@vger.kernel.org" , "masahiroy@kernel.org" , "nico@fluxnic.net" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-renesas-soc@vger.kernel.org" , "a.hajda@samsung.com" , "jonas@kwiboo.se" , "kieran.bingham+renesas@ideasonboard.com" , "Laurent.pinchart@ideasonboard.com" , "jgg@ziepe.ca" , "davem@davemloft.net" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, 16 Apr 2020, Arnd Bergmann wrote: > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed wrote: >> BTW how about adding a new Kconfig option to hide the details of >> ( BAR || !BAR) ? as Jason already explained and suggested, this will >> make it easier for the users and developers to understand the actual >> meaning behind this tristate weird condition. >> >> e.g have a new keyword: >> reach VXLAN >> which will be equivalent to: >> depends on VXLAN && !VXLAN > > I'd love to see that, but I'm not sure what keyword is best. For your > suggestion of "reach", that would probably do the job, but I'm not > sure if this ends up being more or less confusing than what we have > today. Ah, perfect bikeshedding topic! Perhaps "uses"? If the dependency is enabled it gets used as a dependency. Of course, this is all just talk until someone(tm) posts a patch actually making the change. I've looked at the kconfig tool sources before; not going to make the same mistake again. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel