On 2021/10/26 3:01, Marc Kleine-Budde wrote:
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
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?
