netdev - Re: [RFC 0/6] Regressions for "imply" behavior change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 Apr 2020 19:04:27 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "jgg@...pe.ca" <jgg@...pe.ca>
CC:     "narmstrong@...libre.com" <narmstrong@...libre.com>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "Laurent.pinchart@...asonboard.com" 
        <Laurent.pinchart@...asonboard.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "leon@...nel.org" <leon@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "nico@...xnic.net" <nico@...xnic.net>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "kieran.bingham+renesas@...asonboard.com" 
        <kieran.bingham+renesas@...asonboard.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "jani.nikula@...ux.intel.com" <jani.nikula@...ux.intel.com>,
        "a.hajda@...sung.com" <a.hajda@...sung.com>,
        "jonas@...boo.se" <jonas@...boo.se>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "jernej.skrabec@...l.net" <jernej.skrabec@...l.net>
Subject: Re: [RFC 0/6] Regressions for "imply" behavior change

On Fri, 2020-04-10 at 14:13 -0300, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2020 at 02:40:42AM +0000, Saeed Mahameed wrote:
> 
> > This assumes that the module using FOO has its own flag
> > representing
> > FOO which is not always the case.
> > 
> > for example in mlx5 we use VXLAN config flag directly to compile
> > VXLAN
> > related files:
> > 
> > mlx5/core/Makefile:
> > 
> > obj-$(CONFIG_MLX5_CORE) += mlx5_core.o
> > 
> > mlx5_core-y := mlx5_core.o
> > mlx5_core-$(VXLAN) += mlx5_vxlan.o
> > 
> > and in mlx5_main.o we do:
> 
> Does this work if VXLAN = m ?

Yes, if VXLAN IS_REACHABLE to MLX5, mlx5_vxlan.o will be
compiled/linked.

> 
> > if (IS_ENABLED(VXLAN))
> >        mlx5_vxlan_init()
> > 
> > after the change in imply semantics:
> > our options are:
> > 
> > 1) use IS_REACHABLE(VXLAN) instead of IS_ENABLED(VXLAN)
> > 
> > 2) have MLX5_VXLAN in mlx5 Kconfig and use IS_ENABLED(MLX5_VXLAN) 
> > config MLX5_VXLAN
> > 	depends on VXLAN || !VXLAN
> > 	bool
> 
> Does this trick work when vxlan is a bool not a tristate?
> 
> Why not just put the VXLAN || !VXLAN directly on MLX5_CORE?
> 

so force MLX5_CORE to n if vxlan is not reachable ? why ? mlx5_core can
perfectly live without vxlan .. all we need to know is if VXLAN is
supported and reachable, if so, then we want to also support vxlan in
mlx5 (i.e compile mlx5_vxlan.o) 

and how do we compile mlx5_vxlan.o wihout a single flag 
can i do in Makefile :
mlx5_core-$(VXLAN || !VXLAN) += mlx5_vxlan.o ?? 


> Jason