Dealing with SUBLEVEL overflow in backports

Dealing with SUBLEVEL overflow in backports

[Jiaxun Yang]

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

Re: Dealing with SUBLEVEL overflow in backports

[Johannes Berg]

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

Re: Dealing with SUBLEVEL overflow in backports

[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 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

Re: Dealing with SUBLEVEL overflow in backports

[Jiaxun Yang]

在 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

Re: Dealing with SUBLEVEL overflow in backports

[Johannes Berg]

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

Re: Dealing with SUBLEVEL overflow in backports

[Jiaxun Yang]

在 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

Re: Dealing with SUBLEVEL overflow in backports

[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?

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: Dealing with SUBLEVEL overflow in backports

[Jiaxun Yang]

在 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

Re: Dealing with SUBLEVEL overflow in backports

[Johannes Berg]

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

Re: Dealing with SUBLEVEL overflow in backports

[Hauke Mehrtens]

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

Re: Dealing with SUBLEVEL overflow in backports

[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)

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: Dealing with SUBLEVEL overflow in backports

[Jiaxun Yang]

在 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

Re: Dealing with SUBLEVEL overflow in backports

[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?

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: Dealing with SUBLEVEL overflow in backports

[Jiaxun Yang]

在 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

Re: Dealing with SUBLEVEL overflow in backports

[Hauke Mehrtens]

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

Re: Dealing with SUBLEVEL overflow in backports

[Hauke Mehrtens]

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

Re: Dealing with SUBLEVEL overflow in backports

[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)

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

Re: Dealing with SUBLEVEL overflow in backports

[Jiaxun Yang]

在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

Re: Dealing with SUBLEVEL overflow in backports

[Hauke Mehrtens]

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

Re: Dealing with SUBLEVEL overflow in backports

[Johannes Berg]

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