On Fri, 10 Nov 2023, Sebastian Andrzej Siewior wrote: > On 2023-11-09 15:45:54 [-0500], John Kacur wrote: > > diff --git a/Makefile b/Makefile > > index b73e8c13f3e5..14f74e087eff 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -18,7 +18,7 @@ PREFIX := /usr > > DATADIR := $(DESTDIR)/$(PREFIX)/share > > LOADDIR := loadsource > > > > -KLOAD := $(LOADDIR)/linux-6.1.8.tar.xz > > +KLOAD := $(LOADDIR)/linux-6.6.1.tar.xz > > BLOAD := $(LOADDIR)/dbench-4.0.tar.gz > > LOADS := $(KLOAD) $(BLOAD) > > Instead of doing this every now and then you could first limit it to one > place and then build the remaining version coding from that point. > Once that works, step two would be to grab the current version number > from > https://www.kernel.org/finger_banner > > \o/ > > Sebastian > > We have to use a default kernel version that we know works with our current tool chain. Usually when I update the version it's because the older kernel doesn't compile on the latest distribution. For that reason though, we also can't just fetch the latest and greatest that we haven't tested. We have added tools in rteval to make fetching the kernel easier, especially for upstream. rteval -S [kernel-version] will either fetch the kernel-version, or if that is omitted, it will fetch the default-kernel version for rteval from kernel.org I guess what we're lacking is an option to have kcompile use an indicated kernel-version. This could be useful also for testing the version with rteval. John
