On Tue, Aug 22, 2023 at 11:15:08PM -0700, Stanislav Kinsburskii wrote: > On Sat, Aug 26, 2023 at 09:45:39AM +0200, Greg Kroah-Hartman wrote: > > On Tue, Aug 22, 2023 at 06:36:10PM -0700, Stanislav Kinsburskii wrote: > > > > > +#include <linux/bitmap.h> > > > > > +#include <linux/memblock.h> > > > > > +#include <linux/spinlock.h> > > > > > +#include <linux/types.h> > > > > > + > > > > > +#include <linux/pmpool.h> > > > > > + > > > > > +#define VERSION 1 > > > > > > > > In kernel code does not need versions. > > > > > > > > > > Could you elaborate on this? Should kernel version be used as a backward > > > compatitbility marker instead? > > > > kernel versions should never be checked for in-kernel code, so I really > > don't understand the question here sorry. > > > > For code that is in the kernel tree, having "versions" on them (as many > > drivers used to, and now only a few do), makes no sense, especially with > > the stable/lts trees getting fixes for them over time as well. > > > > This version is rather an ABI version. The idea is to make sure, that > any future ABI change is explicit and reflected in the version, so it > can be easily noticed in case of kexec to a kernel with an older > version. > But I guess there are other ways to make sure, that the ABI contract is > the preserved. Which ABI are you referring to here. The user/kernel one? Or the kernel/hypervisor one? Or something else? There is no "numbering" of user/kernel apis, sorry. APIs just don't need that, you can handle things properly automatically without version numbers (as again, that just does not work.) thanks, greg k-h
