RHEL 8.1 backported some fixes from newer kernels so we need to treat it's 4.18 kernel as if it were a newer kernel in some cases.
Signed-off-by: Felix Kaechele felix@kaechele.ca --- compat-include/linux/igmp.h | 2 +- compat-include/linux/uaccess.h | 2 +- compat-include/net/addrconf.h | 2 +- compat.h | 6 ++++++ 4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/compat-include/linux/igmp.h b/compat-include/linux/igmp.h index ecedc915..60606f05 100644 --- a/compat-include/linux/igmp.h +++ b/compat-include/linux/igmp.h @@ -17,7 +17,7 @@
int ip_mc_check_igmp(struct sk_buff *skb);
-#elif LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0) +#elif LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0) && !defined(RHEL_81)
static inline int batadv_ip_mc_check_igmp(struct sk_buff *skb) { diff --git a/compat-include/linux/uaccess.h b/compat-include/linux/uaccess.h index e81ed805..5a337441 100644 --- a/compat-include/linux/uaccess.h +++ b/compat-include/linux/uaccess.h @@ -13,7 +13,7 @@ #include <linux/version.h> #include_next <linux/uaccess.h>
-#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 0, 0) +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 0, 0) && !defined(RHEL_81)
static inline int batadv_access_ok(int type, const void __user *p, unsigned long size) diff --git a/compat-include/net/addrconf.h b/compat-include/net/addrconf.h index b826ee95..5ab19043 100644 --- a/compat-include/net/addrconf.h +++ b/compat-include/net/addrconf.h @@ -17,7 +17,7 @@
int ipv6_mc_check_mld(struct sk_buff *skb);
-#elif LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0) +#elif LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0) && !defined(RHEL_81)
static inline int batadv_ipv6_mc_check_mld(struct sk_buff *skb) { diff --git a/compat.h b/compat.h index 980fca9f..7f4a5ee4 100644 --- a/compat.h +++ b/compat.h @@ -44,6 +44,12 @@
#endif /* < KERNEL_VERSION(4, 15, 0) */
+#ifdef RHEL_RELEASE_CODE +# if RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(8, 1) +# define RHEL_81 +# endif +#endif /* RHEL_RELEASE_CODE */ + #endif /* __KERNEL__ */
#endif /* _NET_BATMAN_ADV_COMPAT_H_ */
On Saturday, 25 January 2020 19:07:45 CET Felix Kaechele wrote:
RHEL 8.1 backported some fixes from newer kernels so we need to treat it's 4.18 kernel as if it were a newer kernel in some cases.
I am personally not really happy about supporting all kind of weird Linux kernel forks.
Anyway, if you really want to maintain the RHEL support (for reasonable versions which are based on reasonable new upstream kernels) then I would propose to avoid this RHEL_81. Instead it might be better to just add RHEL_RELEASE_VERSION + RHEL_RELEASE_CODE [1] to compat-include/linux/version.h. And then just use them like the backports.git is using them [2].
Kind regards, Sven
[1] https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree... [2] https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree...
Hi,
On 2020-01-25 2:17 p.m., Sven Eckelmann wrote:
I am personally not really happy about supporting all kind of weird Linux kernel forks.
No worries. Just saw that there are some provisions for Debian (which I guess is what some of the maintainers are using) in the code. But I do see that all the Ubuntu specific stuff that backports has isn't in there either.
Anyway, if you really want to maintain the RHEL support (for reasonable versions which are based on reasonable new upstream kernels) then I would propose to avoid this RHEL_81. Instead it might be better to just add RHEL_RELEASE_VERSION + RHEL_RELEASE_CODE [1] to compat-include/linux/version.h. And then just use them like the backports.git is using them [2].
I'm not interested in maintaining this upstream indefinitely and I agree with you that carrying around fixes for all kinds of weird quirks is a burden on maintainers.
I'm happy to just carry this patch in my DKMS RPM packages I maintain for batman-adv.
Regards, Felix
On Tuesday, 28 January 2020 18:19:16 CET Felix Kaechele wrote: [..]
No worries. Just saw that there are some provisions for Debian (which I guess is what some of the maintainers are using) in the code.
Good point, there was the make-kpkg hack. @Linus, can this be dropped? The correct way to build a private Debian package of the kernel is to use `make deb-pkg`
[...]
I'm not interested in maintaining this upstream indefinitely and I agree with you that carrying around fixes for all kinds of weird quirks is a burden on maintainers.
I'm happy to just carry this patch in my DKMS RPM packages I maintain for batman-adv.
As said, if you want to maintain it upstream then feel free to resent the patch with the requested change. The "reasonable new upstream kernels" part was about the way we drop support for older kernels. The oldest kernel we want to support is the the oldest kernel not marked as EOL on https://www.kernel.org/category/releases.html
If the RHEL quirks don't become too bothersome and you take care of it then it should be a relative small problem for us. I just don't want to be the person taking care of kernels which I don't use.
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
Felix Kaechele -
Sven Eckelmann