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:   Fri, 20 Jul 2018 12:09:45 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     Netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>,
        Tom Lendacky <thomas.lendacky@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Ariel Elior <ariel.elior@...ium.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Santosh Raspatur <santosh@...lsio.com>, madalin.bucur@....com,
        yisen.zhuang@...wei.com, salil.mehta@...wei.com,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Ganesh Goudar <ganeshgr@...lsio.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        linux-net-drivers@...arflare.com, peppe.cavallaro@...com,
        alexandre.torgue@...com, joabreu@...opsys.com,
        grygorii.strashko@...com, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Subject: Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload

On Thu, Jul 19, 2018 at 02:04:16PM -0700, Alexander Duyck wrote:
> On Thu, Jul 19, 2018 at 1:52 PM, Pablo Neira Ayuso <pablo@...filter.org> wrote:
> > On Thu, Jul 19, 2018 at 08:18:20AM -0700, Alexander Duyck wrote:
> >> On Wed, Jul 18, 2018 at 5:11 PM, Pablo Neira Ayuso <pablo@...filter.org> wrote:
> >> > One of the recurring complaints is that we do not have, as a driver
> >> > writer, a central location from which we would be fed offloading rules
> >> > into a NIC. This was brought up again during Netconf'18 in Boston.
> >> >
> >> > This patch just renames ndo_setup_tc to ndo_setup_offload as a very
> >> > early initial work to prepare for follow up patch that discuss unified
> >> > flow representation for the existing offload programming APIs.
> >> >
> >> > Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>
> >> > Acked-by: Jiri Pirko <jiri@...lanox.com>
> >> > Acked-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> >>
> >> One request I would have here is to not bother updating the individual
> >> driver function names. For now I would say we could leave the
> >> "_setup_tc" in the naming of the driver functions itself and just
> >> update the name of the net device operation. Renaming the driver
> >> functions just adds unnecessary overhead and complexity to the patch
> >> and will make it more difficult to maintain. When we get around to
> >> adding additional functionality that relates to the rename we could
> >> address renaming the function on a per driver basis in the future.
> >
> > Plan was to follow up patch will rename enum tc_setup_type too:
> >
> > https://marc.info/?l=linux-netdev&m=153193158512556&w=2
> >
> > that will result in more renames in the driver side.
> >
> > I would expect this will happen sooner or later, and out of tree
> > patches will end up needing a rebase sooner or later, if that is the
> > concern.
> 
> I was just thinking that renaming the functions themselves adds noise
> and makes it harder to debug functions later when they get renamed. As
> far as the out-of-tree driver I agree we will still have to deal with
> it due to the enum and NDO function rename. I just figured that using
> things like LXR is a bit easier when the function name stays the same
> and you have to move between versions.

Semantic changes in this interface are expected in follow up patches.
Specifically, this interface will not be exclusively dedicated to 'tc'
anymore. The function rename will provide a hint on this semantic change
going on. I understand your concern, and I also tend to dislike renaming
for the sake of renaming, but in this case this rename coveys useful
information to developers.

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ