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

Date:	Thu, 25 Feb 2016 21:44:43 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>, jiri@...nulli.us
Cc:	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

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.

> If all that people can come up with is "device names! omg UDEV!" and
> "multiple tools are hard to use!"  That's awesome, because it means
> nobody has any real substantial objection to this facility. :-)

I do think this is important if a lot of devlinks are visible and they 
don't yet provide a net_device. One has to use e.g. pci identifiers or 
depend on module loading order. Especially I have no idea how this 
should work with devices where the module is not yet loaded (and most 
device drivers don't split between pci layer and net_device). This is 
even more complicated then the udev stuff we have nowadays.

Bye,
Hannes