[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6f8ff1119123f920d1af5203a04acd7d13f6d90.camel@mellanox.com>
Date: Fri, 17 Apr 2020 11:35:40 +0000
From: Saeed Mahameed <saeedm@...lanox.com>
To: "arnd@...db.de" <arnd@...db.de>
CC: "masahiroy@...nel.org" <masahiroy@...nel.org>,
"Laurent.pinchart@...asonboard.com"
<Laurent.pinchart@...asonboard.com>,
"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
"jgg@...pe.ca" <jgg@...pe.ca>,
"nico@...xnic.net" <nico@...xnic.net>,
"airlied@...ux.ie" <airlied@...ux.ie>,
"jernej.skrabec@...l.net" <jernej.skrabec@...l.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"jonas@...boo.se" <jonas@...boo.se>,
"leon@...nel.org" <leon@...nel.org>,
"jani.nikula@...ux.intel.com" <jani.nikula@...ux.intel.com>,
"kieran.bingham+renesas@...asonboard.com"
<kieran.bingham+renesas@...asonboard.com>,
"narmstrong@...libre.com" <narmstrong@...libre.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
Subject: Re: [RFC PATCH 1/2] Kconfig: Introduce "uses" keyword
On Fri, 2020-04-17 at 12:24 +0200, Arnd Bergmann wrote:
> On Fri, Apr 17, 2020 at 3:12 AM Saeed Mahameed <saeedm@...lanox.com>
> wrote:
> > Due to the changes to the semantics of imply keyword [1], which now
> > doesn't force any config options to the implied configs any more.
> >
> > A module (FOO) that has a weak dependency on some other modules
> > (BAR)
> > is now broken if it was using imply to force dependency
> > restrictions.
> > e.g.: FOO needs BAR to be reachable, especially when FOO=y and
> > BAR=m.
> > Which might now introduce build/link errors.
> >
> > There are two options to solve this:
> > 1. use IS_REACHABLE(BAR), everywhere BAR is referenced inside FOO.
> > 2. in FOO's Kconfig add: depends on (BAR || !BAR)
> >
> > The first option is not desirable, and will leave the user confused
> > when
> > setting FOO=y and BAR=m, FOO will never reach BAR even though both
> > are
> > compiled.
> >
> > The 2nd one is the preferred approach, and will guarantee BAR is
> > always
> > reachable by FOO if both are compiled. But, (BAR || !BAR) is really
> > confusing for those who don't really get how kconfig tristate
> > arithmetics
> > work.
> >
> > To solve this and hide this weird expression and to avoid
> > repetition
> > across the tree, we introduce new keyword "uses" to the Kconfig
> > options
> > family.
> >
> > uses BAR:
> > Equivalent to: depends on symbol || !symbol
> > Semantically it means, if FOO is enabled (y/m) and has the option:
> > uses BAR, make sure it can reach/use BAR when possible.
> >
> > For example: if FOO=y and BAR=m, FOO will be forced to m.
> >
> > [1]
> > https://lore.kernel.org/linux-doc/20200302062340.21453-1-masahiroy@kernel.org/
>
> Thanks a lot for getting this done. I've tried it out on my
> randconfig
> build tree
> and can confirm that this works together with your second patch to
> address the
> specific MLX5 problem.
>
> I also tried out replacing all other instances of 'depends on FOO ||
> !FOO', using
> this oneline script:
>
> git ls-files | grep Kconfig | xargs sed -i
> 's:depends.on.\([A-Z0-9_a-z]\+\) || \(\1 \?= \?n\|!\1\):uses \1:'
>
> Unfortunately, this immediately crashes with:
>
> $ make -skj30
> how to free type 0?
> double free or corruption (fasttop)
> make[6]: *** [/git/arm-soc/scripts/kconfig/Makefile:71: olddefconfig]
> Aborted (core dumped)
> make[5]: *** [/git/arm-soc/Makefile:587: olddefconfig] Error 2
> make[4]: *** [/git/arm-soc/scripts/kconfig/Makefile:95:
> allrandom.config] Error 2
> make[3]: *** [/git/arm-soc/Makefile:587: allrandom.config] Error 2
> make[2]: *** [Makefile:180: sub-make] Error 2
> make[2]: Target 'allrandom.config' not remade because of errors.
> make[1]: *** [makefile:127: allrandom.config] Error 2
>
> It's probably easy to fix, but I did not look any deeper into the
> bug.
>
Ahh, I know what it is, i am allocating only one expression for the two
symbols (FOO || !FOO) .. in the rule action in parser.y, i must
allocate two individual instances per each of the FOO appearances ..
something like:
struct expr *symexpr1 = expr_alloc_symbol($2);
struct expr *symexpr2 = expr_alloc_symbol($2);
menu_add_dep(expr_alloc_two(E_OR, symexpr1, expr_alloc_one(E_NOT,
symexpr2)));
Thanks Arnd for testing this ! I will test this and send V2 later.
Powered by blists - more mailing lists