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 for Android: free password hash cracker in your pocket

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

Message-ID: <01f964ae-9c32-7531-1f07-2687616b6a71@samsung.com>
Date:   Thu, 16 Apr 2020 21:56:24 +0200
From:   Andrzej Hajda <a.hajda@...sung.com>
To:     Jason Gunthorpe <jgg@...pe.ca>, Nicolas Pitre <nico@...xnic.net>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "narmstrong@...libre.com" <narmstrong@...libre.com>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "Laurent.pinchart@...asonboard.com" 
        <Laurent.pinchart@...asonboard.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "kieran.bingham+renesas@...asonboard.com" 
        <kieran.bingham+renesas@...asonboard.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 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@...ux.intel.com> wrote:
>>>> On Thu, 16 Apr 2020, Arnd Bergmann <arnd@...db.de> wrote:
>>>>> On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed <saeedm@...lanox.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
>