netdev - Re: [patch net-next 3/9] mlx4: Implement port type setting via devlink interface

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

Date:	Tue, 23 Feb 2016 17:55:23 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, 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
Subject: Re: [patch net-next 3/9] mlx4: Implement port type setting via
 devlink interface

Tue, Feb 23, 2016 at 05:45:07PM CET, hannes@...essinduktion.org wrote:
>On 23.02.2016 17:04, Jiri Pirko wrote:
>>Tue, Feb 23, 2016 at 04:57:17PM CET, hannes@...essinduktion.org wrote:
>>>On 23.02.2016 16:30, Jiri Pirko wrote:
>>>>Tue, Feb 23, 2016 at 04:16:11PM CET, hannes@...essinduktion.org wrote:
>>>>
>>>><snip>
>>>>
>>>>>>>1) is easily solvable, just drop the ifindex style attributes and always
>>>>>>>force the user to enter the bus and bus-topology id.
>>>>>>
>>>>>>But why? Use can easily get that info and map it to devlink index. It
>>>>>>aligns with nl80211 iface.
>>>>>>
>>>>>>Do you really want to do commands like:
>>>>>>myhost:~$ dl dev show pci_0000:01:00.0
>>>>>>?
>>>>>
>>>>>Yes, exactly I would. I would put them into a boot-up script based on my
>>>>>system configuration and can be sure it will work the next boot, too, and
>>>>>adapt them when I replace the hardware or do some configuration changes.
>>>>>
>>>>>I think sysadmins or scripts are the primary users of this interface not
>>>>>kernel developers which switch their settings around all the time, no?
>>>>
>>>>I can easily add this to the userspace tool to accept "pci_0000:01:00.0"
>>>>format and to map it internally to devlink index. No problem.
>>>
>>>I argue for this stable topology identifier to be the default. Especially if
>>>you add device info before the actual module is loaded (this is during
>>>initramfs, when udev cannot rename devlink names to stable ones), a user has
>>>to deal with pre-devlink-ids before rename and after. Do you have plans how
>>>to address that?
>>
>>You can still access devlink using pci_addr using dl. I don't see a
>>problem.
>
>I don't really see a reason why the devlink indexes/names exist inside the
>kernel instead of a stable topology identifier. They confuse users and add
>more unnecessary code to the kernel. Shells have environment variables for
>that. ;) This is a low-level kernel setting tool IMHO.
>
>I just see the problem that users use the devlink* names and we get reports
>because stuff breaks because they don't use the stable identifiers. That is
>all.
>

you can have stable devlink name using udev. For pre-udev usage, you can
use pci address directly. I don't like to use pci address for every
dl command. I would like to have some more convenient name handle -
devlink name.


>>>Current initramfs for stable interface names uses EUI48 based mac addresses
>>>most of the time and udev runs then after the pivot_root.
>>>
>>>The devlink names can easily be aliases in user space.
>>
>>I don't want to store them anywhere. I just use "dl" tool and pass the
>>name there.
>
>Sorry?

you said - "The devlink names can easily be aliases in user space." -
where do you want to store them?