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.
