Thu, Feb 25, 2016 at 10:53:30PM CET, han...@stressinduktion.org wrote: >On 25.02.2016 22:12, Jiri Pirko wrote: >>Thu, Feb 25, 2016 at 09:44:43PM CET, han...@stressinduktion.org wrote: >>>On 25.02.2016 21:12, David Miller wrote: >>>>From: Jiri Pirko <j...@resnulli.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.