linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeedm@mellanox.com>
To: "masahiroy@kernel.org" <masahiroy@kernel.org>,
	"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>,
	"nico@fluxnic.net" <nico@fluxnic.net>
Cc: "Laurent.pinchart@ideasonboard.com" 
	<Laurent.pinchart@ideasonboard.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
	"jgg@ziepe.ca" <jgg@ziepe.ca>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"jernej.skrabec@siol.net" <jernej.skrabec@siol.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jonas@kwiboo.se" <jonas@kwiboo.se>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"kieran.bingham+renesas@ideasonboard.com" 
	<kieran.bingham+renesas@ideasonboard.com>,
	"leon@kernel.org" <leon@kernel.org>
Subject: Re: [RFC PATCH 1/2] Kconfig: Introduce "uses" keyword
Date: Tue, 21 Apr 2020 04:24:10 +0000	[thread overview]
Message-ID: <45b9efec57b2e250e8e39b3b203eb8cee10cb6e8.camel@mellanox.com> (raw)
In-Reply-To: <87v9lu1ra6.fsf@intel.com>

On Mon, 2020-04-20 at 11:43 +0300, Jani Nikula wrote:
> On Sun, 19 Apr 2020, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > On Sun, Apr 19, 2020 at 4:11 AM Nicolas Pitre <nico@fluxnic.net>
> > wrote:
> > > On Sun, 19 Apr 2020, Masahiro Yamada wrote:
> > > 
> > > > (FOO || !FOO) is difficult to understand, but
> > > > the behavior of "uses FOO" is as difficult to grasp.
> > > 
> > > Can't this be expressed as the following instead:
> > > 
> > >         depends on FOO if FOO
> > > 
> > > That would be a little clearer.
> > > 
> > > 
> > > Nicolas
> > 
> > 
> > 'depends on' does not take the 'if <expr>'
> > 
> > 'depends on A if B' is the syntax sugar of
> > 'depends on (A || !B), right ?
> > 
> > I do not know how clearer it would make things.
> > 
> > depends on (m || FOO != m)
> > is another equivalent, but we are always
> > talking about a matter of expression.
> > 
> > 
> > How important is it to stick to
> > depends on (FOO || !FOO)
> > or its equivalents?
> > 
> > 
> > If a driver wants to use the feature FOO
> > in most usecases, 'depends on FOO' is sensible.
> > 
> > If FOO is just optional, you can get rid of the dependency,
> > and IS_REACHABLE() will do logically correct things.
> 
> If by logically correct you mean the kernel builds, you're
> right. However the proliferation of IS_REACHABLE() is making the
> kernel
> config *harder* to understand. User enables FOO=m and expects BAR to
> use
> it, however if BAR=y it silently gets ignored. I have and I will
> oppose
> adding IS_REACHABLE() usage to i915 because it's just silently
> accepting
> configurations that should be flagged and forbidden at kconfig stage.
> 
> > I do not think IS_REACHABLE() is too bad,
> > but if it is confusing, we can add one more
> > option to make it explicit.
> > 
> > 
> > 
> > config DRIVER_X
> >        tristate "driver x"
> > 
> > config DRIVER_X_USES_FOO
> >        bool "use FOO from driver X"
> >        depends on DRIVER_X
> >        depends on DRIVER_X <= FOO
> >        help
> >          DRIVER_X works without FOO, but
> >          Using FOO will provide better usability.
> >          Say Y if you want to make driver X use FOO.
> > 
> > 
> > 
> > Of course,
> > 
> >       if (IS_ENABLED(CONFIG_DRIVER_X_USES_FOO))
> >                foo_init();
> > 
> > works like
> > 
> >       if (IS_REACHABLE(CONFIG_FOO))
> >                 foo_init();
> > 
> > 
> > At lease, it will eliminate a question like
> > "I loaded the module FOO, I swear.
> > But my built-in driver X still would not use FOO, why?"
> 

and duplicate this all over just to avoid new keyword.


> Please let's not make that a more widespread problem than it already
> is. I have yet to hear *one* good rationale for allowing that in the
> first place. And if that pops up, you can make it work by using
> IS_REACHABLE() *without* the depends, simply by checking if the
> module
> is there.
> 
> Most use cases increasingly solved by IS_REACHABLE() should use the
> "depends on FOO || FOO=n" construct, but the problem is that's not
> widely understood. I'd like to have another keyword for people to
> copy-paste into their Kconfigs.
> 

+1 

do all C developers know how the C compiler works ? of course not !
Same goes here, there is a demand for a new keyword, so people will
avoid copy and pate and can use the kconfig language in a higher
simplified level.

I just did a quick grep to find out how really people use depend on:

# All usage of depends on 
$ git ls-files | grep Kconfig | xargs grep -E "depends\s+on" | wc -l
15071

# simple single symbol expression usage 
$ git ls-files | grep Kconfig | xargs grep -E "depends\s+on\s+[A-Za-z0-
9_]+\s*$" | wc -l
8889

almost 60%.. 

people really like simple things especially for the tools they are
using "like kconfig", no one really wants to understand how it really
work under the hood if it is a one time thing that you need to setup
for your kernel project, unless it is really necessary ..

I wonder how many of those 8889 cases wanted a weak dependency but
couldn't figure out how to do it ? 

Users of depends on FOO || !FOO

$ git ls-files | grep Kconfig | xargs grep -E \
  "depends\s+on\s+([A-Za-z0-9_]+)\s*\|\|\s*(\!\s*\1|\1\s*=\s*n)" \
 | wc -l

156

a new keyword is required :) .. 


> In another mail I suggested
> 
> 	optionally depends on FOO
> 
> might be a better alternative than "uses".
> 
> 

how about just:
      optional FOO

It is clear and easy to document .. 


> BR,
> Jani.
> 

  parent reply	other threads:[~2020-04-21  4:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17  1:11 [RFC PATCH 1/2] Kconfig: Introduce "uses" keyword Saeed Mahameed
2020-04-17  1:11 ` [RFC PATCH 2/2] net/mlx5: Kconfig: Use "uses" instead of "imply" Saeed Mahameed
2020-04-17  8:08   ` Arnd Bergmann
2020-04-17  6:23 ` [RFC PATCH 1/2] Kconfig: Introduce "uses" keyword Jani Nikula
2020-04-17 12:28   ` Jason Gunthorpe
2020-04-17 14:01     ` Jani Nikula
2020-04-17 14:07       ` Jason Gunthorpe
2020-04-17 10:24 ` Arnd Bergmann
2020-04-17 11:35   ` Saeed Mahameed
2020-04-18 19:00 ` Masahiro Yamada
2020-04-18 19:11   ` Nicolas Pitre
2020-04-18 20:07     ` Masahiro Yamada
2020-04-20  8:43       ` Jani Nikula
2020-04-20 18:42         ` Jakub Kicinski
2020-04-21  4:24         ` Saeed Mahameed [this message]
2020-04-21 13:58           ` Nicolas Pitre
2020-04-21 16:30             ` Saeed Mahameed
2020-04-21 18:23               ` Nicolas Pitre
2020-04-22  8:51                 ` Jani Nikula
2020-04-22 21:13                   ` Nicolas Pitre
2020-04-22 22:37                     ` Randy Dunlap
2020-04-23 15:01                       ` Nicolas Pitre
2020-04-23 15:05                         ` Jason Gunthorpe
2020-04-23 15:11                           ` Nicolas Pitre
2020-04-23 15:16                             ` Jason Gunthorpe
2020-04-23 15:28                               ` Arnd Bergmann
2020-04-23 15:33                               ` Nicolas Pitre
2020-04-23 18:30                                 ` Jason Gunthorpe
2020-04-23 18:52                                   ` Nicolas Pitre
2020-04-20 13:53   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45b9efec57b2e250e8e39b3b203eb8cee10cb6e8.camel@mellanox.com \
    --to=saeedm@mellanox.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=jani.nikula@linux.intel.com \
    --cc=jernej.skrabec@siol.net \
    --cc=jgg@ziepe.ca \
    --cc=jonas@kwiboo.se \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=leon@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=netdev@vger.kernel.org \
    --cc=nico@fluxnic.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).