On Thu, Jan 11, 2024 at 2:27 PM Morten Brørup wrote: > *From:* Patrick Robb [mailto:probb@iol.unh.edu] > *Sent:* Thursday, 11 January 2024 20.02 > > > > On Thu, Jan 11, 2024 at 4:18 AM Morten Brørup > wrote: > > > I wonder if any automated tests are using this specific kernel version, or > if we are only testing using the distros' native kernels. @Aaron? > > > > For UNH, we generally run from the distros' native kernels. Any exceptions > are not for testing older kernel versions, so we don't have anything > running from 4.14 in our testing right now. > > > > If running some automated testing for, say, the minimum supported kernel > version at any point in time is a value to anyone, certainly they can speak > up and we can discuss adding that. > > > > > > When the documentation specifies a minimum required kernel version, it > implicitly claims that DPDK works with that kernel version. > > So we should either test with the specified kernel version (which requires > significant effort to set up, so I’m not going to ask for it!), or add a > big fat disclaimer/warning that DPDK is not tested with the mentioned > kernel version, and list the kernel versions actually tested. > Well, adding one system which moves with the minimum supported kernel version probably wouldn't be too onerous, so I will add a ticket noting this as a community request. On the other hand, one of the reasons we're moving to running more and more of our testing from containers is so that we don't have to do as much VM "babysitting" and our testing environment is more cleanly defined. Obviously that doesn't apply in this case, so we'd set up a custom VM for this testing job specifically. But, as an LTS kernel version reaches EOL approximately 1x per year, it shouldn't be too bad. > > > As an appliance vendor, we build our systems from scratch, including the > bootloader, kernel and file systems. We don’t use any of the distro stuff. > > Having information about well tested kernel versions would be helpful when > choosing kernel version for our appliances. I suppose other appliance > vendors also use their own hardened/purpose-built kernel versions, and > would consider this information useful for their decision process too. > > > Maybe the best thing we can do without a significant overhaul of our process is to more explicitly display the kernel version for a system when reporting results. If others chime in and there is big interest here, we can go further.