netdev - Re: [patch net-next v2 0/9] Introduce devlink interface and first drivers to use it

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]

Message-ID: <20160225225803.GA2191@nanopsycho.orion>
Date:	Thu, 25 Feb 2016 23:58:03 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	idosch@...lanox.com, eladr@...lanox.com, yotamg@...lanox.com,
	ogerlitz@...lanox.com, yishaih@...lanox.com, dledford@...hat.com,
	sean.hefty@...el.com, hal.rosenstock@...il.com,
	eugenia@...lanox.com, roopa@...ulusnetworks.com,
	nikolay@...ulusnetworks.com, hadarh@...lanox.com, jhs@...atatu.com,
	john.fastabend@...il.com, jeffrey.t.kirsher@...el.com,
	brouer@...hat.com, ivecera@...hat.com, rami.rosen@...el.com,
	gospo@...ulusnetworks.com
Subject: Re: [patch net-next v2 0/9] Introduce devlink interface and first
 drivers to use it

Thu, Feb 25, 2016 at 10:53:30PM CET, hannes@...essinduktion.org wrote:
>On 25.02.2016 22:12, Jiri Pirko wrote:
>>Thu, Feb 25, 2016 at 09:44:43PM CET, hannes@...essinduktion.org wrote:
>>>On 25.02.2016 21:12, David Miller wrote:
>>>>From: Jiri Pirko <jiri@...nulli.us>
>>>>Date: Tue, 23 Feb 2016 16:51:25 +0100
>>>>
>>>>>There a is need for some userspace API that would allow to expose things
>>>>>that are not directly related to any device class like net_device of
>>>>>ib_device, but rather chip-wide/switch-ASIC-wide stuff.
>>>>>
>>>>>Use cases:
>>>>>1) get/set of port type (Ethernet/InfiniBand)
>>>>>2) setting up port splitters - split port into multiple ones and squash again,
>>>>>    enables usage of splitter cable
>>>>>3) setting up shared buffers - shared among multiple ports within
>>>>>    one chip (work in progress)
>>>>>4) configuration of switch wide properties - resources division etc - This will
>>>>>    allow to pass configuration that is unacceptable to be passed as
>>>>>    a module option.
>>>>>
>>>>>First patch of this set introduces a new generic Netlink based interface,
>>>>>called "devlink". It is similar to nl80211 model and it is heavily
>>>>>influenced by it, including the API definition. The devlink introduction patch
>>>>>implements use cases 1) and 2). Other 2 are in development atm and will
>>>>>be addressed by follow-ups.
>>>>>
>>>>>It is very convenient for drivers to use devlink, as you can see in other
>>>>>patches in this set.
>>>>>
>>>>>Counterpart for devlink is userspace tool for now called "dl". Command line
>>>>>interface and outputs are derived from "ip" tool so it should be easy
>>>>>for users to get used to it.
>>>>
>>>>I am very close to applying this series as-is.
>>>>
>>>>The clincher for me is that there is precendence in the nl80211 stuff,
>>>>so obviously whatever userland infrastructure sits on top of that has
>>>>found a way to deal whatever perceived shortcomings devlink has.
>>>
>>>Actually nl80211 phy interfaces aren't really managed by wpa_supplicant nor
>>>NetworkManager, but they use net_device names to discover those later on. In
>>>devlink we don't necessarily have netdev names, thus my only objection to
>>>this series is to switch to stable topology identifiers.
>>
>>Hannes, as I mentioned earlier in one of my replies, you can choose to
>>use devlink name or pci (or other) address for your commands. So you
>>have your stable names even before udev takes care of renaming. It's up
>>to you as a user what handle to use.
>
>I understood that part from the beginning. In my opinion we should simply
>keep APIs simple and clean, reduced to the minimum and let user space build
>upon this.
>
>If an entity in the kernel doesn't need a name and/or a naming database, I
>would not bother implementing it. Not everyone is a kernel developer who uses
>Linux and can infer the problems from dl --help. I bet most users will use
>names at some point in time and they simply can't match even with the udev
>quirks in place when setting up netbooting or configuration must happen from
>the currently provided initramfs. This is my point.
>
>If names are fragile to use simply don't provide it if not necessary.
>
>devlink is an interface of its own and the names won't be referenced by other
>subsystems like iptables -i <name> or iproute. So why bother with names in
>the kernel?
>
>On the rest with netlink etc. I agree already. I just want to eliminate
>possible mistakes by users.
>
>Hope that makes my point more clear,

Okay. You convinced me. Will send v3 removing in-kernel naming and
indexing of devlinks and will only use bus type and bus name as a handle.

Thanks.