On 25.10.2021 10:45:05, Jakub Kicinski wrote:
quoted
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 |