Hi,
commit 92833e8b5db6c209e9311ac8c6a44d3bf1856659 breaks the build of sch_* modules in stable.
I already have:
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 20, 0) qdisc_destroy(cl->leaf.q); #else qdisc_put(cl->leaf.q); #endif
But this makes it more tricky… or can I “just” change this to KERNEL_VERSION(4, 19, 221) ?
Nevertheless, renaming functions isn’t something I’d expect to happen in stable. At least add a #define or so redirecting from the old/stable name…
bye, //mirabilos
On Sun, 27 Mar 2022, Thorsten Glaser wrote:
But this makes it more tricky… or can I “just” change this to KERNEL_VERSION(4, 19, 221) ?
Well, of course not:
$ cat /usr/src/linux-headers-4.19.0-19-amd64/include/generated/uapi/linux/version.h #define LINUX_VERSION_CODE 267263 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) $ print $(((267263 >> 16) & 0xFF)).$(((267263 >> 8) & 0xFF)).$((267263 & 0xFF)) 4.19.255
Whose bright idea was *that*?
How can I make this module compatible with *both* 4.19 variants?
Thanks in advance, //mirabilos
On Sun, Mar 27, 2022 at 11:44:59PM +0200, Thorsten Glaser wrote:
On Sun, 27 Mar 2022, Thorsten Glaser wrote:
But this makes it more tricky… or can I “just” change this to KERNEL_VERSION(4, 19, 221) ?
Well, of course not:
$ cat /usr/src/linux-headers-4.19.0-19-amd64/include/generated/uapi/linux/version.h #define LINUX_VERSION_CODE 267263 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) $ print $(((267263 >> 16) & 0xFF)).$(((267263 >> 8) & 0xFF)).$((267263 & 0xFF)) 4.19.255
Whose bright idea was *that*?
How can I make this module compatible with *both* 4.19 variants?
Ah, external code, sorry, you are on your own.
As for how to test for larger numbers, see the answer in the email archives, others have done this successfully.
good luck!
greg k-h
On Mon, 28 Mar 2022, Greg Kroah-Hartman wrote:
How can I make this module compatible with *both* 4.19 variants?
Ah, external code, sorry, you are on your own.
This is… no, I’m going to have to censor my thoughts on this response.
(Besides, these are patched version of in-tree modules to experiment with new network features.)
As for how to test for larger numbers, see the answer in the email archives, others have done this successfully.
good luck!
Search engine fodder would have been welcome. All I found so far is https://lwn.net/ml/linux-kernel/20210208145805.898658055@linuxfoundation.org... in which you speak of mysterious “different ways of extracting the version number” that “out of tree modules have”, I’d love to see them.
bye, //mirabilos
Dixi quod…
On Mon, 28 Mar 2022, Greg Kroah-Hartman wrote:
As for how to test for larger numbers, see the answer in the email archives, others have done this successfully.
Search engine fodder would have been welcome. All I found so far is
I’ve figured out enough Makefile and cpp hackery… after finally finding out that I need to take the values on Makefile level, not from a header file… so, for the archives (and for the benefit of others):
https://github.com/tarent/sch_jens/commit/19c8e499fba8cef65a0b301dc158168707...
bye, //mirabilos
On Sun, Mar 27, 2022 at 11:39:10PM +0200, Thorsten Glaser wrote:
Hi,
commit 92833e8b5db6c209e9311ac8c6a44d3bf1856659 breaks the build of sch_* modules in stable.
Where do these sch_* modules live? In the kernel tree itself? I have not gotten any failed build errors here, what config option do I need to enable?
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Thorsten Glaser