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: <20211025190114.zbqgzsfiv7zav7aq@pengutronix.de>
Date:   Mon, 25 Oct 2021 21:01:14 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Guangbin Huang <huangguangbin2@...wei.com>, 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 25.10.2021 10:45:05, Jakub Kicinski wrote:
> > The approach Andrew suggested is two-fold. First introduce a "struct
> > ethtool_kringparam" that's only used inside the kernel, as "struct
> > ethtool_ringparam" is ABI. Then extend "struct ethtool_kringparam" as
> > needed.
> 
> 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;
| };

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)