Stephen Hemminger <step...@networkplumber.org> writes:
> On Thu, 21 Apr 2022 11:40:00 -0400 > Ray Kinsella <m...@ashroe.eu> wrote: > >> Stephen Hemminger <step...@networkplumber.org> writes: >> >> > On Thu, 21 Apr 2022 12:38:26 +0800 >> > Stephen Coleman <omegacole...@gmail.com> wrote: >> > >> >> KNI ioctl functions copy data from userspace lib, and this interface >> >> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko >> >> bad things happen: sometimes various fields contain garbage value, >> >> sometimes it cause a kmod soft lockup. >> >> >> >> Some common distros ship their own rte_kni.ko, so this is likely to >> >> happen. >> >> >> >> This patch add abi version checking between userland lib and kmod so >> >> that: >> >> >> >> * if kmod ioctl got a wrong abi magic, it refuse to go on >> >> * if userland lib, probed a wrong abi version via newly added ioctl, it >> >> also refuse to go on >> >> >> >> Bugzilla ID: 998 >> > >> > >> > Kernel API's are supposed to be 99% stable. >> > If this driver was playing by the upstream kernel rules this would not >> > have happened. >> >> Well look, it is out-of-tree and never likely to be in-tree, so those >> rules don't apply. Making sure the ABI doesn't change during the ABI >> stablity period, should be good enough? >> > > I think if KNI changes, it should just add more ioctl numbers and > be compatible, it is not that hard. True, fair point, I am unsure what that buys us though. My thinking was that we should be doing the minimal amount of work on KNI, and directing people to use upstream alternatives where possible. For me minimizing means DPDK ABI alignment. However I see your point, let KNI maintain it own ABI versioning independent of DPDK, with stricter kernel-like guarantees is probably not much more work. -- Regards, Ray K
