On 2021/10/26 3:01, Marc Kleine-Budde wrote:

On 25.10.2021 10:45:05, Jakub Kicinski wrote:

quoted

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

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?