netdev - Re: [PATCH net-next] devlink: Delete not-used devlink APIs

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, 16 Sep 2021 07:11:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...dia.com>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] devlink: Delete not-used devlink APIs

On Thu, 16 Sep 2021 16:52:02 +0300 Leon Romanovsky wrote:
> > The port_param functions are "symmetric" with the global param 
> > ones. Removing them makes the API look somewhat incomplete.  
> 
> There is no value in having "complete" API that no one uses.

Well, for an API which we are hoping to attract vendors to, the
"completeness" could be useful. If kernel needs to be extended
some will fall back to their out of tree tools.

> > Obviously the general guidance is that we shouldn't export 
> > functions which have no upstream users but that applies to 
> > meaningful APIs. For all practical purposes this is just a 
> > sliver of an API, completeness gives nice warm feelings.  
> 
> It is misleading, I have much more warm feeling when I see API that is
> used. Once it will be needed, the next developer will copy/paste it
> pretty fast.
> 
> > Anyway, just curious what made you do this. I wouldn't do it 
> > myself but neither am I substantially opposed.  
> 
> Move of devlink_register() to be last command in the devlink init flow
> and removal of devlink_*_publish() calls as an outcome of that.

Alrighty:

Acked-by: Jakub Kicinski <kuba@...nel.org>