5 Commits (b58e8b10faab5f68122e2badd3f01a57532bbf56)

Author	SHA1	Message	Date
Andrew Yager	de94f85bfb	MT#55283 kernel-module: detect nft_expr_ops.validate signature via compile test ... The current LINUX_VERSION_CODE check for the nft_expr_ops.validate callback signature breaks on distribution kernels that backport the API change (mainline commit eaf9b2c875ec, merged in 6.12) without updating LINUX_VERSION_CODE. For example, Ubuntu 24.04's 6.8.0-103+ kernel (stable patchset 2026-01-27, LP: #2139158) includes this backport, causing DKMS builds to fail with -Werror=incompatible-pointer-types. Replace the version-based #if with a compile test in the existing gen-rtpengine-kmod-flags configure script. The test tries to assign a 3-param function to .validate -- if it compiles, the old API is present and NFT_EXPR_OPS_VALIDATE_HAS_DATA is set. If it fails, the kernel has the new 2-param version. Also use kbuild's KERNELRELEASE variable (instead of uname -r) to resolve the kernel build directory, so that compile tests and KSRC target the correct kernel during cross-version DKMS builds. Tested against Ubuntu 6.8.0-90 (3-param) and 6.8.0-106 (2-param), including cross-kernel builds where the running kernel differs from the DKMS target. Closes #2085 Change-Id: I4c8e55b94fb98c3fcda9dccb091d0d1c0c67f9aa (cherry picked from commit b1aec46de8) (cherry picked from commit 4ea947f755)	2 months ago
Richard Fuchs	3d3cef9d0b	MT#55283 improve version handling ... Change-Id: I8ff496f8460c5c5e0bee6b6bb6f3d2245291c597 (cherry picked from commit 7e6c2c30a4) (cherry picked from commit 857be2dd71)	5 months ago
Richard Fuchs	35674a22fc	MT#55283 honour .release-version also for .ko ... Change-Id: If145e018248444b9b6a30a4b6ee5984ab27ca8fd (cherry picked from commit 02916e72c8) (cherry picked from commit 6303d93859)	5 months ago
Richard Fuchs	277bd13d97	MT#55283 fix kernel version generating booboo ... Also make shellcheck happy. Change-Id: Ic8a7bd67866ef2c75dec40dbe4207fc92ef31ed2	1 year ago
Guillem Jover	7dbe24e4e5	MT#61993 build: Rework to use a config.mk generated during the build ... These are potentially computed from inside each subdir, and in addition due to what appears to be a regression in GNU make 4.4, where it is reevaluating variables that contain $(shell) functions, many times (in the order of thousands, this was slowing down the build, were on the Debian amd64 build daemons it went from 5m with GNU make 4.3 to 2h40m with GNU make 4.4. Although the bulk of the slow down has been fixed with previous commits, the remaining optimizations are only to avoid this potentially happening again in the future, and to reduce useless duplicate work. Instead of trying to cache the values from within make itself, where programming this there is extremely painful, and does not seem to be able to greatly reduce the number of calls, because the build system is going to be called multiple times for different targets. Simply externalize the generation into several shell scripts, that we call to generate a make fragment that then we include from the various Makefiles. For a Debian build with GNU make 4.3, this reduces the amount of total pkg-config calls from around ~1600 to 128, for dpkg-buildflags from ~1100 down to 6, and for dpkg-parsechangelog from ~56 to 17, but the slow down is not as significant there anyway. For a Debian build with GNU make 4.4, this reduces the amount of total pkg-config calls from around ~2600 to 128, for dpkg-buildflags from ~2800 down to 6, and for dpkg-parsechangelog from ~350 to 21. For a Debian build with GNU make 4.4, this reduces the build time on this system from 2m10s to ~ 1m30s. Change-Id: I427d0ea5106dc6ed1ff9e664ccdba2fa0725b7d0	2 years ago