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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19D08EEAA54 for ; Thu, 14 Sep 2023 15:56:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241268AbjINP46 (ORCPT ); Thu, 14 Sep 2023 11:56:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240667AbjINP4z (ORCPT ); Thu, 14 Sep 2023 11:56:55 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D07CB1BDD; Thu, 14 Sep 2023 08:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694707012; x=1726243012; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=sjnm9j0exQ8kWr8SJac5qRGJ+LAGIH1ZXOdQmtHpGXE=; b=SiHmhm6foJEnFyG/rGFMMcAXA7ho6GK/GFPu+blg0EXP6KkTYVSZggLp fa9psn67MexnLZ1kDmLVcGLiZ23/DF4m9T3hRlrQrj6dNLV4KNBaCGDL8 8Gim7MgQOQxXXeKWUKS1ZzHY1/mzIDeHBNtAraP5HhGz4B4Bzl2Xxo1B2 Gy5O/6Ee3wOgLWMV96Fa010ZHD4PU+n/8A99O0fFHGSo7wMLVwoYYztIa weqNQhdVFTESMjK9bmavk/bw0FmVDEK8RgoUHlLd6gMqZ7K90rBaKGh/r LJVcSdSYMUCMdlSbmHq40ZB0LqXZdwJV+2KPEFIVqdhDvKtFBn28ENox7 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10833"; a="378913726" X-IronPort-AV: E=Sophos;i="6.02,146,1688454000"; d="scan'208";a="378913726" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2023 08:56:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10833"; a="1075437508" X-IronPort-AV: E=Sophos;i="6.02,146,1688454000"; d="scan'208";a="1075437508" Received: from jnikula-mobl4.fi.intel.com (HELO localhost) ([10.237.66.162]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2023 08:56:45 -0700 From: Jani Nikula To: Arnd Bergmann , Arnd Bergmann , Masahiro Yamada , Jonathan Corbet Cc: Sakari Ailus , Javier Martinez Canillas , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Documentation: kbuild: explain handling optional dependencies In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20230913113801.1901152-1-arnd@kernel.org> <874jjwx44g.fsf@intel.com> Date: Thu, 14 Sep 2023 18:56:42 +0300 Message-ID: <87v8ccvjd1.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Sep 2023, "Arnd Bergmann" wrote: > On Thu, Sep 14, 2023, at 15:42, Jani Nikula wrote: >> On Wed, 13 Sep 2023, Arnd Bergmann wrote: >>> From: Arnd Bergmann >>> >>> +Optional dependencies >>> +~~~~~~~~~~~~~~~~~~~~~ >>> + >>> +Some drivers are able to optionally use a feature from another module >>> +or build cleanly with that module disabled, but cause a link failure >>> +when trying to use that loadable module from a built-in driver. >>> + >>> +The most common way to express this optional dependency in Kconfig logic >>> +uses the slighly counterintuitive >>> + >>> + config FOO >>> + bool "Support for foo hardware" >>> + depends on BAR || !BAR >> >> depends on BAR || BAR=n >> >> seems to be an alternative that's about as common: >> >> $ git grep "depends on \([A-Z0-9_]\+\) || \!\1" | wc -l >> 109 >> $ git grep "depends on \([A-Z0-9_]\+\) || \1=n" | wc -l >> 107 >> >> Maybe worth mentioning both? > > I fear that would add more confusion than it avoids: > "!BAR" is actually different from "BAR=n", but *head explodes* > "BAR || !BAR" is the same as "BAR || BAR=n" here, and > trying to explain this in the documentation would either > make it incorrect or unhelpfully complicated. Fair enough. BR, Jani. -- Jani Nikula, Intel