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 |
Attachment:
signature.asc
Description: PGP signature
