netdev - Re: [PATCH next 3/3] ipvlan: Introduce l3s mode

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] [day] [month] [year] [list]

Date:   Sat, 10 Sep 2016 11:48:52 -0700
From:   Mahesh Bandewar (महेश बंडेवार) 
        <maheshb@...gle.com>
To:     David Miller <davem@...emloft.net>
Cc:     dsa@...ulusnetworks.com, mahesh@...dewar.net,
        linux-netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH next 3/3] ipvlan: Introduce l3s mode

On Sat, Sep 10, 2016 at 11:11 AM, David Miller <davem@...emloft.net> wrote:
> From: David Ahern <dsa@...ulusnetworks.com>
> Date: Sat, 10 Sep 2016 10:25:27 -0600
>
>> On 9/9/16 4:46 PM, Mahesh Bandewar (महेश बंडेवार) wrote:
>>> On Fri, Sep 9, 2016 at 3:26 PM, David Ahern <dsa@...ulusnetworks.com> wrote:
>>>> On 9/9/16 3:53 PM, Mahesh Bandewar wrote:
>>>>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>>>>> index 0c5415b05ea9..95edd1737ab5 100644
>>>>> --- a/drivers/net/Kconfig
>>>>> +++ b/drivers/net/Kconfig
>>>>> @@ -149,6 +149,7 @@ config IPVLAN
>>>>>      tristate "IP-VLAN support"
>>>>>      depends on INET
>>>>>      depends on IPV6
>>>>> +    select NET_L3_MASTER_DEV
>>>>
>>>> depends on instead of select?
>>>
>>> The kbuild/kconfig-language.txt suggests that for "depends on" the
>>> option _must_ be selected otherwise menuconfig wont even present the
>>> dependent option while select positively sets the option.
>>
>> understood. VRF driver uses 'depends on'
>
> Select is for things that are largely invisible to the user.  It is more of
> a brute force tool that has several limitations.  For one, it doesn't
> recursively apply dependencies of the thing you selected.  This makes it
> quite trivial to create situations where you select X but it actually
> can't work because it's "depend" statements aren't satisfied.
>
I look at "select" as more of a tool than brute-force / hack. It
allows to "select" something that is largely independent and otherwise
not really harmful (of for that matter even useful). Now if you look
at L3_MASTER, it's not really useful if the users of this feature (VRF
or IPvlan) are not chosen. Hence I would say "select" fits in this
scenario better (I mean for IPvlan or VRF driver choosing select over
depend) However I agree that if you "select" some option which has
dependencies and it becomes ambiguous but that's not the case here.

> Depend is really the thing you ought to use, and yes this means that the
> user has to know to enable the thing you depend upon to make your feature
> available.  But that's just how it works.
I thought "select" is a better choice for the said reasons. I don't
mind changing it to "depend" but it would make it difficult for novice
users to figure-out why they can't see this driver-config.