From: Andrzej Hajda <a.hajda@samsung.com> To: Jason Gunthorpe <jgg@ziepe.ca>, Nicolas Pitre <nico@fluxnic.net> Cc: Arnd Bergmann <arnd@arndb.de>, Jani Nikula <jani.nikula@linux.intel.com>, Saeed Mahameed <saeedm@mellanox.com>, "narmstrong@baylibre.com" <narmstrong@baylibre.com>, "masahiroy@kernel.org" <masahiroy@kernel.org>, "Laurent.pinchart@ideasonboard.com" <Laurent.pinchart@ideasonboard.com>, "leon@kernel.org" <leon@kernel.org>, "davem@davemloft.net" <davem@davemloft.net>, "linux-renesas-soc@vger.kernel.org" <linux-renesas-soc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "kieran.bingham+renesas@ideasonboard.com" <kieran.bingham+renesas@ideasonboard.com>, "jonas@kwiboo.se" <jonas@kwiboo.se>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "airlied@linux.ie" <airlied@linux.ie>, "jernej.skrabec@siol.net" <jernej.skrabec@siol.net> Subject: Re: [RFC 0/6] Regressions for "imply" behavior change Date: Thu, 16 Apr 2020 21:56:24 +0200 [thread overview] Message-ID: <01f964ae-9c32-7531-1f07-2687616b6a71@samsung.com> (raw) In-Reply-To: <20200416182106.GX5100@ziepe.ca> On 16.04.2020 20:21, Jason Gunthorpe wrote: > On Thu, Apr 16, 2020 at 11:12:56AM -0400, Nicolas Pitre wrote: >> On Thu, 16 Apr 2020, Arnd Bergmann wrote: >> >>> On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula >>> <jani.nikula@linux.intel.com> wrote: >>>> On Thu, 16 Apr 2020, Arnd Bergmann <arnd@arndb.de> wrote: >>>>> On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed <saeedm@mellanox.com> 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. >>> That seems to be the best naming suggestion so far >> What I don't like about "uses" is that it doesn't convey the conditional >> dependency. It could be mistaken as being synonymous to "select". >> >> What about "depends_if" ? The rationale is that this is actually a >> dependency, but only if the related symbol is set (i.e. not n or empty). > I think that stretches the common understanding of 'depends' a bit too > far.. A depends where the target can be N is just too strange. > > Somthing incorporating 'optional' seems like a better choice > 'optionally uses' seems particularly clear and doesn't overload > existing works like depends or select I think the whole misunderstanding with imply is that ppl try to use it as weak 'depend on' but it is weak 'select' - ie it enforces value of implied symbol in contrast to 'depends' which enforces value of current symbol. So if we want to add new symbol 'weak depend' it would be good to stress out that difference. Moreover name imply is already cryptic, adding another keyword which for sure will be cryptic (as there are no natural candidates) will complicate things more. Maybe adding some decorator would be better, like optionally or weak, for example: optionally depends on X optionally select Y Even more readable: depends on X if on depends on Y if enabled Regards Andrzej > > Jason >
WARNING: multiple messages have this Message-ID (diff)
From: Andrzej Hajda <a.hajda@samsung.com> To: Jason Gunthorpe <jgg@ziepe.ca>, Nicolas Pitre <nico@fluxnic.net> Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "airlied@linux.ie" <airlied@linux.ie>, "jernej.skrabec@siol.net" <jernej.skrabec@siol.net>, "leon@kernel.org" <leon@kernel.org>, Arnd Bergmann <arnd@arndb.de>, "narmstrong@baylibre.com" <narmstrong@baylibre.com>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "masahiroy@kernel.org" <masahiroy@kernel.org>, "jonas@kwiboo.se" <jonas@kwiboo.se>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-renesas-soc@vger.kernel.org" <linux-renesas-soc@vger.kernel.org>, Saeed Mahameed <saeedm@mellanox.com>, "kieran.bingham+renesas@ideasonboard.com" <kieran.bingham+renesas@ideasonboard.com>, "Laurent.pinchart@ideasonboard.com" <Laurent.pinchart@ideasonboard.com>, "davem@davemloft.net" <davem@davemloft.net> Subject: Re: [RFC 0/6] Regressions for "imply" behavior change Date: Thu, 16 Apr 2020 21:56:24 +0200 [thread overview] Message-ID: <01f964ae-9c32-7531-1f07-2687616b6a71@samsung.com> (raw) In-Reply-To: <20200416182106.GX5100@ziepe.ca> On 16.04.2020 20:21, Jason Gunthorpe wrote: > On Thu, Apr 16, 2020 at 11:12:56AM -0400, Nicolas Pitre wrote: >> On Thu, 16 Apr 2020, Arnd Bergmann wrote: >> >>> On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula >>> <jani.nikula@linux.intel.com> wrote: >>>> On Thu, 16 Apr 2020, Arnd Bergmann <arnd@arndb.de> wrote: >>>>> On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed <saeedm@mellanox.com> 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. >>> That seems to be the best naming suggestion so far >> What I don't like about "uses" is that it doesn't convey the conditional >> dependency. It could be mistaken as being synonymous to "select". >> >> What about "depends_if" ? The rationale is that this is actually a >> dependency, but only if the related symbol is set (i.e. not n or empty). > I think that stretches the common understanding of 'depends' a bit too > far.. A depends where the target can be N is just too strange. > > Somthing incorporating 'optional' seems like a better choice > 'optionally uses' seems particularly clear and doesn't overload > existing works like depends or select I think the whole misunderstanding with imply is that ppl try to use it as weak 'depend on' but it is weak 'select' - ie it enforces value of implied symbol in contrast to 'depends' which enforces value of current symbol. So if we want to add new symbol 'weak depend' it would be good to stress out that difference. Moreover name imply is already cryptic, adding another keyword which for sure will be cryptic (as there are no natural candidates) will complicate things more. Maybe adding some decorator would be better, like optionally or weak, for example: optionally depends on X optionally select Y Even more readable: depends on X if on depends on Y if enabled Regards Andrzej > > Jason > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-16 19:56 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-08 20:27 [RFC 0/6] Regressions for "imply" behavior change Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 1/6] thunder: select PTP driver if possible Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 2/6] net/mlx5e: fix VXLAN dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 3/6] LiquidIO VF: add dependency for PTP_1588_CLOCK Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 21:10 ` kbuild test robot 2020-04-08 21:13 ` Arnd Bergmann 2020-04-08 20:27 ` [RFC 4/6] drm/bridge/sii8620: fix extcon dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-10 6:56 ` Andrzej Hajda 2020-04-10 6:56 ` Andrzej Hajda 2020-04-14 15:04 ` Arnd Bergmann 2020-04-14 15:04 ` Arnd Bergmann 2020-04-14 15:37 ` Daniel Vetter 2020-04-14 15:37 ` Daniel Vetter 2020-04-15 6:58 ` Jani Nikula 2020-04-15 6:58 ` Jani Nikula 2020-04-08 20:27 ` [RFC 5/6] drm/rcar-du: fix selection of CMM driver Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-14 20:17 ` Laurent Pinchart 2020-04-14 20:17 ` Laurent Pinchart 2020-04-14 20:38 ` Arnd Bergmann 2020-04-14 20:38 ` Arnd Bergmann 2020-04-14 20:51 ` Laurent Pinchart 2020-04-14 20:51 ` Laurent Pinchart 2020-04-14 21:10 ` Arnd Bergmann 2020-04-14 21:10 ` Arnd Bergmann 2020-04-15 14:13 ` Geert Uytterhoeven 2020-04-15 14:13 ` Geert Uytterhoeven 2020-04-15 15:18 ` Arnd Bergmann 2020-04-15 15:18 ` Arnd Bergmann 2020-04-15 19:07 ` Arnd Bergmann 2020-04-15 19:07 ` Arnd Bergmann 2020-04-15 21:12 ` Laurent Pinchart 2020-04-15 21:12 ` Laurent Pinchart 2020-04-15 21:22 ` Arnd Bergmann 2020-04-15 21:22 ` Arnd Bergmann 2020-04-16 6:51 ` Daniel Vetter 2020-04-16 6:51 ` Daniel Vetter 2020-04-16 15:17 ` Laurent Pinchart 2020-04-16 15:17 ` Laurent Pinchart 2020-04-08 20:27 ` [RFC 6/6] drm/rcar-du: fix lvds dependency Arnd Bergmann 2020-04-08 20:27 ` Arnd Bergmann 2020-04-08 20:38 ` [RFC 0/6] Regressions for "imply" behavior change Nicolas Pitre 2020-04-08 20:38 ` Nicolas Pitre 2020-04-08 20:46 ` Saeed Mahameed 2020-04-08 20:46 ` Saeed Mahameed 2020-04-08 20:49 ` Arnd Bergmann 2020-04-08 20:49 ` Arnd Bergmann 2020-04-08 21:17 ` Nicolas Pitre 2020-04-08 21:17 ` Nicolas Pitre 2020-04-08 22:42 ` Jason Gunthorpe 2020-04-08 22:42 ` Jason Gunthorpe 2020-04-09 8:41 ` Jani Nikula 2020-04-09 8:41 ` Jani Nikula 2020-04-10 2:40 ` Saeed Mahameed 2020-04-10 2:40 ` Saeed Mahameed 2020-04-10 7:26 ` Geert Uytterhoeven 2020-04-10 7:26 ` Geert Uytterhoeven 2020-04-10 17:13 ` Jason Gunthorpe 2020-04-10 17:13 ` Jason Gunthorpe 2020-04-10 19:04 ` Saeed Mahameed 2020-04-10 19:04 ` Saeed Mahameed 2020-04-14 13:29 ` Jason Gunthorpe 2020-04-14 13:29 ` Jason Gunthorpe 2020-04-14 14:27 ` Arnd Bergmann 2020-04-14 14:27 ` Arnd Bergmann 2020-04-14 15:23 ` Jason Gunthorpe 2020-04-14 15:23 ` Jason Gunthorpe 2020-04-14 15:25 ` Arnd Bergmann 2020-04-14 15:25 ` Arnd Bergmann 2020-04-14 17:49 ` Saeed Mahameed 2020-04-14 17:49 ` Saeed Mahameed 2020-04-14 18:47 ` Arnd Bergmann 2020-04-14 18:47 ` Arnd Bergmann 2020-04-16 3:25 ` Saeed Mahameed 2020-04-16 3:25 ` Saeed Mahameed 2020-04-16 7:20 ` Arnd Bergmann 2020-04-16 7:20 ` Arnd Bergmann 2020-04-16 10:17 ` Jani Nikula 2020-04-16 10:17 ` Jani Nikula 2020-04-16 12:38 ` Arnd Bergmann 2020-04-16 12:38 ` Arnd Bergmann 2020-04-16 14:52 ` Jason Gunthorpe 2020-04-16 14:52 ` Jason Gunthorpe 2020-04-16 15:58 ` Arnd Bergmann 2020-04-16 15:58 ` Arnd Bergmann 2020-04-16 18:05 ` Jason Gunthorpe 2020-04-16 18:05 ` Jason Gunthorpe 2020-04-16 18:38 ` Saeed Mahameed 2020-04-16 18:38 ` Saeed Mahameed 2020-04-16 15:12 ` Nicolas Pitre 2020-04-16 15:12 ` Nicolas Pitre 2020-04-16 18:21 ` Jason Gunthorpe 2020-04-16 18:21 ` Jason Gunthorpe 2020-04-16 19:56 ` Andrzej Hajda [this message] 2020-04-16 19:56 ` Andrzej Hajda
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=01f964ae-9c32-7531-1f07-2687616b6a71@samsung.com \ --to=a.hajda@samsung.com \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=airlied@linux.ie \ --cc=arnd@arndb.de \ --cc=davem@davemloft.net \ --cc=dri-devel@lists.freedesktop.org \ --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-kernel@vger.kernel.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=masahiroy@kernel.org \ --cc=narmstrong@baylibre.com \ --cc=netdev@vger.kernel.org \ --cc=nico@fluxnic.net \ --cc=saeedm@mellanox.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.