netdev - Re: [PATCH V4 net-next 4/6] ethtool: extend ringparam setting uAPI with rx_buf

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]

Message-ID: <20211026075544.65256820@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 26 Oct 2021 07:55:44 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "huangguangbin (A)" <huangguangbin2@...wei.com>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>, <davem@...emloft.net>,
        <mkubecek@...e.cz>, <andrew@...n.ch>, <amitc@...lanox.com>,
        <idosch@...sch.org>, <danieller@...dia.com>,
        <jesse.brandeburg@...el.com>, <anthony.l.nguyen@...el.com>,
        <jdike@...toit.com>, <richard@....at>,
        <anton.ivanov@...bridgegreys.com>, <netanel@...zon.com>,
        <akiyano@...zon.com>, <saeedb@...zon.com>, <chris.snook@...il.com>,
        <ulli.kroll@...glemail.com>, <linus.walleij@...aro.org>,
        <jeroendb@...gle.com>, <csully@...gle.com>,
        <awogbemila@...gle.com>, <jdmason@...zu.us>,
        <rain.1986.08.12@...il.com>, <zyjzyj2000@...il.com>,
        <kys@...rosoft.com>, <haiyangz@...rosoft.com>, <mst@...hat.com>,
        <jasowang@...hat.com>, <doshir@...are.com>,
        <pv-drivers@...are.com>, <jwi@...ux.ibm.com>,
        <kgraul@...ux.ibm.com>, <hca@...ux.ibm.com>, <gor@...ux.ibm.com>,
        <johannes@...solutions.net>, <netdev@...r.kernel.org>,
        <lipeng321@...wei.com>, <chenhao288@...ilicon.com>,
        <linux-s390@...r.kernel.org>
Subject: Re: [PATCH V4 net-next 4/6] ethtool: extend ringparam setting uAPI
 with rx_buf_len

On Tue, 26 Oct 2021 22:41:19 +0800 huangguangbin (A) wrote:
> On 2021/10/26 3:01, Marc Kleine-Budde wrote:
> > On 25.10.2021 10:45:05, Jakub Kicinski wrote:  
> >> Indeed, there are different ways to extend the API for drivers,
> >> I think it comes down to personal taste. I find the "inheritance"
> >> models in C (kstruct usually contains the old struct as some "base")
> >> awkward.
> >>
> >> I don't think we have agreed-on best practice in the area.  
> > 
> >  From my point of view, if there already is an extension mainline:
> > 
> > | https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f3ccfda19319
> > 
> > I'm more in the flavor for modeling other extensions the same way. Would
> > be more consistent to name the new struct "kernel_"ethtool_ringparam,
> > following the coalescing example:
> > 
> > | struct kernel_ethtool_ringparam {
> > |        __u32   rx_buf_len;

nit: no __, just u32. It's not uAPI.

> > | };
> > 
> > regards,
> > Marc
> >   
> We think ethtool_ringparam_ext is more easy to understand it is extension of
> struct ethtool_ringparam. However, we don't mind to keep the same way and modify
> to the name kernel_ethtool_ringparam if everyone agrees.
> 
> Does anyone have other opinions?

Either way is fine by me. Andrew's way is fine too, as long as we don't
embed the old structure into the new one but translate field-by-field.