* Dealing with SUBLEVEL overflow in backports @ 2022-02-07 1:19 Jiaxun Yang 2022-02-07 9:15 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Jiaxun Yang @ 2022-02-07 1:19 UTC (permalink / raw) To: backports; +Cc: Hauke Mehrtens Hi backport forks, I was trying to fix ckmake FAIL building against 4.9 for 4.9.297+. I found that macro KERNEL_VERSION_IN_RANGE(4,9,297, 4,10,0) won't work because SUBLEVEL 297 had overflowed 4 bit (255) in KERNEL_VERSION. How are we supposed to deal with such situation? Thanks. - Jiaxun -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 1:19 Dealing with SUBLEVEL overflow in backports Jiaxun Yang @ 2022-02-07 9:15 ` Johannes Berg 2022-02-07 10:50 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-07 9:15 UTC (permalink / raw) To: Jiaxun Yang, backports; +Cc: Hauke Mehrtens On Mon, 2022-02-07 at 01:19 +0000, Jiaxun Yang wrote: > Hi backport forks, > > I was trying to fix ckmake FAIL building against 4.9 for 4.9.297+. > > I found that macro KERNEL_VERSION_IN_RANGE(4,9,297, 4,10,0) won't work > because SUBLEVEL 297 had overflowed 4 bit (255) in KERNEL_VERSION. > > How are we supposed to deal with such situation? > Hm. I guess the only way would be to somehow make a Kconfig variable in backports, that uses the Makefile settings? But env="SUBLEVEL" doesn't work, so not sure, maybe some Makefile trickery to extract it and write it to the config? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 9:15 ` Johannes Berg @ 2022-02-07 10:50 ` Johannes Berg 2022-02-07 11:09 ` Jiaxun Yang 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-07 10:50 UTC (permalink / raw) To: Jiaxun Yang, backports; +Cc: Hauke Mehrtens On Mon, 2022-02-07 at 10:15 +0100, Johannes Berg wrote: > On Mon, 2022-02-07 at 01:19 +0000, Jiaxun Yang wrote: > > Hi backport forks, > > > > I was trying to fix ckmake FAIL building against 4.9 for 4.9.297+. > > > > I found that macro KERNEL_VERSION_IN_RANGE(4,9,297, 4,10,0) won't work > > because SUBLEVEL 297 had overflowed 4 bit (255) in KERNEL_VERSION. > > > > How are we supposed to deal with such situation? > > > > Hm. I guess the only way would be to somehow make a Kconfig variable in > backports, that uses the Makefile settings? But env="SUBLEVEL" doesn't > work, so not sure, maybe some Makefile trickery to extract it and write > it to the config? > Or just find a way to handle the specific area? Is this for the build_bug.h stuff? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 10:50 ` Johannes Berg @ 2022-02-07 11:09 ` Jiaxun Yang 2022-02-07 11:11 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Jiaxun Yang @ 2022-02-07 11:09 UTC (permalink / raw) To: Johannes Berg, backports; +Cc: Hauke Mehrtens 在 2022/2/7 10:50, Johannes Berg 写道: > On Mon, 2022-02-07 at 10:15 +0100, Johannes Berg wrote: >> On Mon, 2022-02-07 at 01:19 +0000, Jiaxun Yang wrote: >>> Hi backport forks, >>> >>> I was trying to fix ckmake FAIL building against 4.9 for 4.9.297+. >>> >>> I found that macro KERNEL_VERSION_IN_RANGE(4,9,297, 4,10,0) won't work >>> because SUBLEVEL 297 had overflowed 4 bit (255) in KERNEL_VERSION. >>> >>> How are we supposed to deal with such situation? >>> >> Hm. I guess the only way would be to somehow make a Kconfig variable in >> backports, that uses the Makefile settings? But env="SUBLEVEL" doesn't >> work, so not sure, maybe some Makefile trickery to extract it and write >> it to the config? Or is it possible to persuade stable forks to define LINUX_VERSION_SUBLEVEL on existing stable releases? >> > Or just find a way to handle the specific area? Is this for the > build_bug.h stuff? Yes, any idea? Thanks. - Jiaxun > > johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 11:09 ` Jiaxun Yang @ 2022-02-07 11:11 ` Johannes Berg 2022-02-07 12:52 ` Jiaxun Yang 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-07 11:11 UTC (permalink / raw) To: Jiaxun Yang, backports; +Cc: Hauke Mehrtens On Mon, 2022-02-07 at 11:09 +0000, Jiaxun Yang wrote: > > 在 2022/2/7 10:50, Johannes Berg 写道: > > On Mon, 2022-02-07 at 10:15 +0100, Johannes Berg wrote: > > > On Mon, 2022-02-07 at 01:19 +0000, Jiaxun Yang wrote: > > > > Hi backport forks, > > > > > > > > I was trying to fix ckmake FAIL building against 4.9 for 4.9.297+. > > > > > > > > I found that macro KERNEL_VERSION_IN_RANGE(4,9,297, 4,10,0) won't work > > > > because SUBLEVEL 297 had overflowed 4 bit (255) in KERNEL_VERSION. > > > > > > > > How are we supposed to deal with such situation? > > > > > > > Hm. I guess the only way would be to somehow make a Kconfig variable in > > > backports, that uses the Makefile settings? But env="SUBLEVEL" doesn't > > > work, so not sure, maybe some Makefile trickery to extract it and write > > > it to the config? > Or is it possible to persuade stable forks to define LINUX_VERSION_SUBLEVEL > on existing stable releases? Probably not. > > > > > Or just find a way to handle the specific area? Is this for the > > build_bug.h stuff? > Yes, any idea? > Looking at commit b29eec6c49, does it even matter? We can continue using bug.h which includes build_bug.h, it's just pulling in more than needed. johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 11:11 ` Johannes Berg @ 2022-02-07 12:52 ` Jiaxun Yang 2022-02-07 13:04 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Jiaxun Yang @ 2022-02-07 12:52 UTC (permalink / raw) To: Johannes Berg, backports; +Cc: Hauke Mehrtens 在 2022/2/7 11:11, Johannes Berg 写道: > > Looking at commit b29eec6c49, does it even matter? We can continue using > bug.h which includes build_bug.h, it's just pulling in more than needed. Sorry, in which tree? Thanks. - Jiaxun > > johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 12:52 ` Jiaxun Yang @ 2022-02-07 13:04 ` Johannes Berg 2022-02-07 13:40 ` Jiaxun Yang 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-07 13:04 UTC (permalink / raw) To: Jiaxun Yang, backports; +Cc: Hauke Mehrtens On Mon, 2022-02-07 at 12:52 +0000, Jiaxun Yang wrote: > > 在 2022/2/7 11:11, Johannes Berg 写道: > > > > Looking at commit b29eec6c49, does it even matter? We can continue using > > bug.h which includes build_bug.h, it's just pulling in more than needed. > Sorry, in which tree? > In 4.9.x. Basically, we _cannot_ include build_bug.h where we know for sure it does *not* exist, since that would be a compile error. We don't _want_ to include bug.h from build_bug.h if we can avoid it, since it's bigger and more stuff. But for 4.9.x, I'm not sure we need to change anything, since we'll include bug.h from build_bug.h which should continue to work? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 13:04 ` Johannes Berg @ 2022-02-07 13:40 ` Jiaxun Yang 2022-02-07 13:57 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Jiaxun Yang @ 2022-02-07 13:40 UTC (permalink / raw) To: Johannes Berg, backports; +Cc: Hauke Mehrtens 在 2022/2/7 13:04, Johannes Berg 写道: > On Mon, 2022-02-07 at 12:52 +0000, Jiaxun Yang wrote: >> 在 2022/2/7 11:11, Johannes Berg 写道: >>> Looking at commit b29eec6c49, does it even matter? We can continue using >>> bug.h which includes build_bug.h, it's just pulling in more than needed. >> Sorry, in which tree? >> > In 4.9.x. > > Basically, we _cannot_ include build_bug.h where we know for sure it > does *not* exist, since that would be a compile error. > > We don't _want_ to include bug.h from build_bug.h if we can avoid it, > since it's bigger and more stuff. > > But for 4.9.x, I'm not sure we need to change anything, since we'll > include bug.h from build_bug.h which should continue to work? Sorry I didn't follow, the problem for 4.9.297+ is when we are including bug.h, it just include build_bug.h from backport-include. Then in backport-include build_bug.h, the include_next is excluded so the real build_bug.h from kernel tree is never included and thus those macros supposed to be in build_bug.h can never work. Thanks. - Jiaxun > > johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 13:40 ` Jiaxun Yang @ 2022-02-07 13:57 ` Johannes Berg 2022-02-07 22:18 ` Hauke Mehrtens 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-07 13:57 UTC (permalink / raw) To: Jiaxun Yang, backports; +Cc: Hauke Mehrtens On Mon, 2022-02-07 at 13:40 +0000, Jiaxun Yang wrote: > > Sorry I didn't follow, the problem for 4.9.297+ is when we are including > bug.h, it just include build_bug.h from backport-include. > Then in backport-include build_bug.h, the include_next is excluded so > the real build_bug.h from kernel tree is never included and thus those > macros supposed to be in build_bug.h can never work. > Ah! Now I understand. Hmm, don't think I have a solution off the top of my head ... johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 13:57 ` Johannes Berg @ 2022-02-07 22:18 ` Hauke Mehrtens 2022-02-08 7:58 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Hauke Mehrtens @ 2022-02-07 22:18 UTC (permalink / raw) To: Johannes Berg, Jiaxun Yang, backports On 2/7/22 14:57, Johannes Berg wrote: > On Mon, 2022-02-07 at 13:40 +0000, Jiaxun Yang wrote: >> >> Sorry I didn't follow, the problem for 4.9.297+ is when we are including >> bug.h, it just include build_bug.h from backport-include. >> Then in backport-include build_bug.h, the include_next is excluded so >> the real build_bug.h from kernel tree is never included and thus those >> macros supposed to be in build_bug.h can never work. >> > > Ah! Now I understand. Hmm, don't think I have a solution off the top of > my head ... > > johannes Hi, The LINUX_VERSION_CODE is fixed since 4.9.255, see here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=42efb098c75f9d4b95f7cf35d3d52e80cc2fde82 SUBLEVEL should still contains the minor kernel version number. We could extend the macros in backport/backport-include/linux/version.h to check for SUBLEVEL manually if it overflows. Hauke -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-07 22:18 ` Hauke Mehrtens @ 2022-02-08 7:58 ` Johannes Berg 2022-02-08 14:50 ` Jiaxun Yang 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-08 7:58 UTC (permalink / raw) To: Hauke Mehrtens, Jiaxun Yang, backports On Mon, 2022-02-07 at 23:18 +0100, Hauke Mehrtens wrote: > > The LINUX_VERSION_CODE is fixed since 4.9.255, see here: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=42efb098c75f9d4b95f7cf35d3d52e80cc2fde82 > > SUBLEVEL should still contains the minor kernel version number. > > We could extend the macros in backport/backport-include/linux/version.h > to check for SUBLEVEL manually if it overflows. > Right, but the thing is we don't have SUBLEVEL in the *C* code, only in the Makefile. However, stupid me? This is trivial: --- a/Makefile.kernel +++ b/Makefile.kernel @@ -60,3 +60,5 @@ obj-$(CPTCFG_WLAN) += drivers/net/wireless/ #obj-$(CPTCFG_USB_USBNET) += drivers/net/usb/ # #obj-$(CPTCFG_STAGING) += drivers/staging/ + +subdir-ccflags-y += -DCOMPAT_KERNEL_SUBLEVEL=$(SUBLEVEL) (whatever the name is) johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-08 7:58 ` Johannes Berg @ 2022-02-08 14:50 ` Jiaxun Yang 2022-02-08 15:02 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Jiaxun Yang @ 2022-02-08 14:50 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens, backports 在 2022/2/8 7:58, Johannes Berg 写道: > On Mon, 2022-02-07 at 23:18 +0100, Hauke Mehrtens wrote: >> The LINUX_VERSION_CODE is fixed since 4.9.255, see here: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=42efb098c75f9d4b95f7cf35d3d52e80cc2fde82 >> >> SUBLEVEL should still contains the minor kernel version number. >> >> We could extend the macros in backport/backport-include/linux/version.h >> to check for SUBLEVEL manually if it overflows. >> > Right, but the thing is we don't have SUBLEVEL in the *C* code, only in > the Makefile. > > However, stupid me? This is trivial: > > --- a/Makefile.kernel > +++ b/Makefile.kernel > @@ -60,3 +60,5 @@ obj-$(CPTCFG_WLAN) += drivers/net/wireless/ > #obj-$(CPTCFG_USB_USBNET) += drivers/net/usb/ > # > #obj-$(CPTCFG_STAGING) += drivers/staging/ > + > +subdir-ccflags-y += -DCOMPAT_KERNEL_SUBLEVEL=$(SUBLEVEL) > > > (whatever the name is) Ah I tried this approach but find that this may break other modules depending on our headers because the cflag won't come with be inherited by them. So probably we need to generate a header for this purpose as well. Thanks. - Jiaxun > > johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-08 14:50 ` Jiaxun Yang @ 2022-02-08 15:02 ` Johannes Berg 2022-02-08 15:51 ` Jiaxun Yang 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-08 15:02 UTC (permalink / raw) To: Jiaxun Yang, Hauke Mehrtens, backports On Tue, 2022-02-08 at 14:50 +0000, Jiaxun Yang wrote: > > Ah I tried this approach but find that this may break other modules > depending on our headers because the cflag won't come with be > inherited by them. > Hm. I thought about if that could happen, but decided not? We only compile C files in backports, which other parts would break? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-08 15:02 ` Johannes Berg @ 2022-02-08 15:51 ` Jiaxun Yang 2022-02-09 23:44 ` Hauke Mehrtens 0 siblings, 1 reply; 20+ messages in thread From: Jiaxun Yang @ 2022-02-08 15:51 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens, backports 在 2022/2/8 15:02, Johannes Berg 写道: > On Tue, 2022-02-08 at 14:50 +0000, Jiaxun Yang wrote: >> Ah I tried this approach but find that this may break other modules >> depending on our headers because the cflag won't come with be >> inherited by them. >> > Hm. I thought about if that could happen, but decided not? We only > compile C files in backports, which other parts would break? For example OpenWRT compiles mac80211 purely from backports. So for other out-of-tree wireless drivers they have to include headers provided by backports, but they can't recieve cflags from our makefile. So it will leave those macros undefined ad led to problems. Thanks. - Jiaxun > > johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-08 15:51 ` Jiaxun Yang @ 2022-02-09 23:44 ` Hauke Mehrtens 2022-02-09 23:45 ` Hauke Mehrtens 2022-02-10 8:17 ` Johannes Berg 0 siblings, 2 replies; 20+ messages in thread From: Hauke Mehrtens @ 2022-02-09 23:44 UTC (permalink / raw) To: Jiaxun Yang, Johannes Berg, backports On 2/8/22 16:51, Jiaxun Yang wrote: > > > 在 2022/2/8 15:02, Johannes Berg 写道: >> On Tue, 2022-02-08 at 14:50 +0000, Jiaxun Yang wrote: >>> Ah I tried this approach but find that this may break other modules >>> depending on our headers because the cflag won't come with be >>> inherited by them. >>> >> Hm. I thought about if that could happen, but decided not? We only >> compile C files in backports, which other parts would break? > > For example OpenWRT compiles mac80211 purely from backports. > > So for other out-of-tree wireless drivers they have to include headers > provided by backports, but they can't recieve cflags from our makefile. > > So it will leave those macros undefined ad led to problems. > > Thanks. > - Jiaxun > >> >> johannes > Hi, What build problem do you get when you include "#include <linux/bug.h>" here on kernel 4.9.299? Can we somehow work around this problem by detection the kernel version in a different way based on a different define? Hauke -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-09 23:44 ` Hauke Mehrtens @ 2022-02-09 23:45 ` Hauke Mehrtens 2022-02-10 8:17 ` Johannes Berg 1 sibling, 0 replies; 20+ messages in thread From: Hauke Mehrtens @ 2022-02-09 23:45 UTC (permalink / raw) To: Jiaxun Yang, Johannes Berg, backports On 2/10/22 00:44, Hauke Mehrtens wrote: > On 2/8/22 16:51, Jiaxun Yang wrote: >> >> >> 在 2022/2/8 15:02, Johannes Berg 写道: >>> On Tue, 2022-02-08 at 14:50 +0000, Jiaxun Yang wrote: >>>> Ah I tried this approach but find that this may break other modules >>>> depending on our headers because the cflag won't come with be >>>> inherited by them. >>>> >>> Hm. I thought about if that could happen, but decided not? We only >>> compile C files in backports, which other parts would break? >> >> For example OpenWRT compiles mac80211 purely from backports. >> >> So for other out-of-tree wireless drivers they have to include headers >> provided by backports, but they can't recieve cflags from our makefile. >> >> So it will leave those macros undefined ad led to problems. >> >> Thanks. >> - Jiaxun >> >>> >>> johannes >> > Hi, > > What build problem do you get when you include "#include <linux/bug.h>" > here on kernel 4.9.299? Can we somehow work around this problem by > detection the kernel version in a different way based on a different > define? > > Hauke OpenWrt does not use kernel 4.9 any more, we could also drop the support for some external modules using backports on such old kernel versions. Hauke -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-09 23:44 ` Hauke Mehrtens 2022-02-09 23:45 ` Hauke Mehrtens @ 2022-02-10 8:17 ` Johannes Berg 2022-02-10 14:05 ` Jiaxun Yang 1 sibling, 1 reply; 20+ messages in thread From: Johannes Berg @ 2022-02-10 8:17 UTC (permalink / raw) To: Hauke Mehrtens, Jiaxun Yang, backports On Thu, 2022-02-10 at 00:44 +0100, Hauke Mehrtens wrote: > > What build problem do you get when you include "#include <linux/bug.h>" > here on kernel 4.9.299? > I haven't tried, but per the explanation, you get issues if you tried to include bug.h in the first place, since then you get bug.h -> includes build_bug.h (since the patch) -> uses build_bug.h from backports -> includes bug.h (does nothing, double include) and you're then missing the defines from build_bug.h. > Can we somehow work around this problem by > detection the kernel version in a different way based on a different define? > I don't think so. However, I don't yet see why passing the version on the command line doesn't work, since we only ever need to care about files we compile? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-10 8:17 ` Johannes Berg @ 2022-02-10 14:05 ` Jiaxun Yang 2022-04-03 23:19 ` Hauke Mehrtens 0 siblings, 1 reply; 20+ messages in thread From: Jiaxun Yang @ 2022-02-10 14:05 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens, backports 在2022年2月10日二月 上午8:17,Johannes Berg写道: > On Thu, 2022-02-10 at 00:44 +0100, Hauke Mehrtens wrote: >> >> What build problem do you get when you include "#include <linux/bug.h>" >> here on kernel 4.9.299? >> > > I haven't tried, but per the explanation, you get issues if you tried to > include bug.h in the first place, since then you get > > bug.h > -> includes build_bug.h (since the patch) > -> uses build_bug.h from backports > -> includes bug.h (does nothing, double include) > Yep that's the problem. What I'm trying is something like: Though it won't work in kernel intergration mode. My makefile foo does not allow me to come up a idea. diff --git a/backport/Makefile.real b/backport/Makefile.real index 65508028..26482e52 100644 --- a/backport/Makefile.real +++ b/backport/Makefile.real @@ -83,8 +83,19 @@ backport-include/backport/autoconf.h: .config Kconfig.versions Kconfig.kernel ) > backport-include/backport/autoconf.h @echo " done." +.PHONY: backport-include/backport/version.h +backport-include/backport/version.h: + @echo -n "Building backport-include/backport/version.h ..." + @echo "#ifndef COMPAT_VERSION_INCLUDED" > $@ + @echo "#define COMPAT_VERSION_INCLUDED" >> $@ + @echo '#define COMPAT_LINUX_VERSION $(VERSION)' >> $@ + @echo '#define COMPAT_LINUX_PATCHLEVEL $(PATCHLEVEL)' >> $@ + @echo '#define COMPAT_LINUX_SUBLEVEL $(SUBLEVEL)' >> $@ + @echo "#endif" >> $@ + @echo " done." + .PHONY: modules -modules: backport-include/backport/autoconf.h +modules: backport-include/backport/autoconf.h backport-include/backport/version.h @$(MAKE) -f Makefile.build modules .PHONY: install diff --git a/backport/backport-include/linux/version.h b/backport/backport-include/linux/version.h index 2cb601ad..06684ffa 100644 --- a/backport/backport-include/linux/version.h +++ b/backport/backport-include/linux/version.h @@ -1,5 +1,7 @@ #ifndef _BP_LINUX_VERSION_H #define _BP_LINUX_VERSION_H + +#include <backport/version.h> #include_next <linux/version.h> #ifndef RHEL_RELEASE_VERSION @@ -10,8 +12,17 @@ #define RHEL_RELEASE_CODE 0 #endif -#define LINUX_VERSION_IS_LESS(x1,x2,x3) (LINUX_VERSION_CODE < KERNEL_VERSION(x1,x2,x3)) -#define LINUX_VERSION_IS_GEQ(x1,x2,x3) (LINUX_VERSION_CODE >= KERNEL_VERSION(x1,x2,x3)) +#define COMPACT_KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c)) + +#define COMPACT_LINUX_VERSION_CODE \ + COMPACT_KERNEL_VERSION(COMPAT_LINUX_VERSION, \ + COMPAT_LINUX_PATCHLEVEL, \ + COMPAT_LINUX_SUBLEVEL) + +#define LINUX_VERSION_IS_LESS(x1,x2,x3) \ + (COMPACT_LINUX_VERSION_CODE < COMPACT_KERNEL_VERSION(x1,x2,x3)) +#define LINUX_VERSION_IS_GEQ(x1,x2,x3) \ + (COMPACT_LINUX_VERSION_CODE >= COMPACT_KERNEL_VERSION(x1,x2,x3)) #define LINUX_VERSION_IN_RANGE(x1,x2,x3, y1,y2,y3) \ (LINUX_VERSION_IS_GEQ(x1,x2,x3) && LINUX_VERSION_IS_LESS(y1,y2,y3)) #endif /* _BP_LINUX_VERSION_H */ [...] -- - Jiaxun -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-02-10 14:05 ` Jiaxun Yang @ 2022-04-03 23:19 ` Hauke Mehrtens 2022-05-04 12:04 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Hauke Mehrtens @ 2022-04-03 23:19 UTC (permalink / raw) To: Jiaxun Yang, Johannes Berg, backports On 2/10/22 15:05, Jiaxun Yang wrote: > > > 在2022年2月10日二月 上午8:17,Johannes Berg写道: >> On Thu, 2022-02-10 at 00:44 +0100, Hauke Mehrtens wrote: >>> >>> What build problem do you get when you include "#include <linux/bug.h>" >>> here on kernel 4.9.299? >>> >> >> I haven't tried, but per the explanation, you get issues if you tried to >> include bug.h in the first place, since then you get >> >> bug.h >> -> includes build_bug.h (since the patch) >> -> uses build_bug.h from backports >> -> includes bug.h (does nothing, double include) >> > > Yep that's the problem. > > What I'm trying is something like: > Though it won't work in kernel intergration mode. My makefile foo does not > allow me to come up a idea. > > diff --git a/backport/Makefile.real b/backport/Makefile.real > index 65508028..26482e52 100644 > --- a/backport/Makefile.real > +++ b/backport/Makefile.real > @@ -83,8 +83,19 @@ backport-include/backport/autoconf.h: .config Kconfig.versions Kconfig.kernel > ) > backport-include/backport/autoconf.h > @echo " done." > > +.PHONY: backport-include/backport/version.h > +backport-include/backport/version.h: > + @echo -n "Building backport-include/backport/version.h ..." > + @echo "#ifndef COMPAT_VERSION_INCLUDED" > $@ > + @echo "#define COMPAT_VERSION_INCLUDED" >> $@ > + @echo '#define COMPAT_LINUX_VERSION $(VERSION)' >> $@ > + @echo '#define COMPAT_LINUX_PATCHLEVEL $(PATCHLEVEL)' >> $@ > + @echo '#define COMPAT_LINUX_SUBLEVEL $(SUBLEVEL)' >> $@ > + @echo "#endif" >> $@ > + @echo " done." > + > .PHONY: modules > -modules: backport-include/backport/autoconf.h > +modules: backport-include/backport/autoconf.h backport-include/backport/version.h > @$(MAKE) -f Makefile.build modules This does not work for me. We have to do this inside the kernel make call, when the kernel build system calls backports again, we should have the needed information in that call only. The build works like this: 1. The normal make call to backports, KERNELRELEASE is not set and Makefile forwards the call to Makefile.real. 2. This calls "Makefile.build modules" in the next step. 3. This calls the kernel build system with "@$(MAKE) -C $(KLIB_BUILD) M=$(BACKPORT_DIR) modules" 4. This calls again Makefile, but now with KERNELRELEASE set. 5. This calls Makefile.kernel and uses the kernel build system to build the backports code. I tried adding a new rule to Makefile.kernel and then call it in Makefile.build using the kernel build system, but it looks like it only supports make targets supported by the kernel build system. How do we make the kernel build system call our make target first? Hauke -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Dealing with SUBLEVEL overflow in backports 2022-04-03 23:19 ` Hauke Mehrtens @ 2022-05-04 12:04 ` Johannes Berg 0 siblings, 0 replies; 20+ messages in thread From: Johannes Berg @ 2022-05-04 12:04 UTC (permalink / raw) To: Hauke Mehrtens, Jiaxun Yang, backports On Mon, 2022-04-04 at 01:19 +0200, Hauke Mehrtens wrote: > > This does not work for me. > We have to do this inside the kernel make call, when the kernel build > system calls backports again, we should have the needed information in > that call only. > > The build works like this: > 1. The normal make call to backports, KERNELRELEASE is not set and > Makefile forwards the call to Makefile.real. > 2. This calls "Makefile.build modules" in the next step. > 3. This calls the kernel build system with > "@$(MAKE) -C $(KLIB_BUILD) M=$(BACKPORT_DIR) modules" > 4. This calls again Makefile, but now with KERNELRELEASE set. > 5. This calls Makefile.kernel and uses the kernel build system to build > the backports code. > > I tried adding a new rule to Makefile.kernel and then call it in > Makefile.build using the kernel build system, but it looks like it only > supports make targets supported by the kernel build system. > > How do we make the kernel build system call our make target first? > Maybe we don't need one? subdir-ccflags-y += -DBACKPORT_KERNEL_SUBLEVEL=$(SUBLEVEL) would pass it to each and every command line ... not nice, but maybe works? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-05-04 12:04 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-02-07 1:19 Dealing with SUBLEVEL overflow in backports Jiaxun Yang 2022-02-07 9:15 ` Johannes Berg 2022-02-07 10:50 ` Johannes Berg 2022-02-07 11:09 ` Jiaxun Yang 2022-02-07 11:11 ` Johannes Berg 2022-02-07 12:52 ` Jiaxun Yang 2022-02-07 13:04 ` Johannes Berg 2022-02-07 13:40 ` Jiaxun Yang 2022-02-07 13:57 ` Johannes Berg 2022-02-07 22:18 ` Hauke Mehrtens 2022-02-08 7:58 ` Johannes Berg 2022-02-08 14:50 ` Jiaxun Yang 2022-02-08 15:02 ` Johannes Berg 2022-02-08 15:51 ` Jiaxun Yang 2022-02-09 23:44 ` Hauke Mehrtens 2022-02-09 23:45 ` Hauke Mehrtens 2022-02-10 8:17 ` Johannes Berg 2022-02-10 14:05 ` Jiaxun Yang 2022-04-03 23:19 ` Hauke Mehrtens 2022-05-04 12:04 ` Johannes Berg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.