On Mon, 25 Oct 2021 15:27:18 +0200 Marc Kleine-Budde wrote: > On 25.10.2021 15:11:49, Marc Kleine-Budde wrote: > > On 14.10.2021 19:39:41, Guangbin Huang wrote: > > > From: Hao Chen <chenhao288@xxxxxxxxxxxxx> > > > > > > Add two new parameters ringparam_ext and extack for > > > .get_ringparam and .set_ringparam to extend more ring params > > > through netlink. > > > > > > Signed-off-by: Hao Chen <chenhao288@xxxxxxxxxxxxx> > > > Signed-off-by: Guangbin Huang <huangguangbin2@xxxxxxxxxx> > > > > While discussing a different ethtool ring param extension, > > Let me explain my requirements: > > There is a not Ethernet based bus system, called CAN (mainly used in the > automotive and industrial world). It comes in 2 different generations or > modes (CAN-2.0 and CAN-FD) and the 3rd one CAN-XL has already been > specified. > > Due to different frame sizes used in these CAN modes and HW limitations, > we need the possibility to set a RX/TX ring configuration for each of > these modes. > > 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.
