Thread (5 messages) 5 messages, 3 authors, 2017-07-14

Re: [PATCH] backfire: fix build failure for 4.11+ kernels

From: John Kacur <jkacur@redhat.com>
Date: 2017-07-14 00:06:18
Subsystem: kernel build + files below scripts/ (unless maintained elsewhere), the rest · Maintainers: Nathan Chancellor, Nicolas Schier, Linus Torvalds


On Thu, 13 Jul 2017, Uwe Kleine-König wrote:
Hello John,

On Thu, Jul 13, 2017 at 05:26:08PM +0200, John Kacur wrote:
quoted
On Wed, 12 Jul 2017, Uwe Kleine-König wrote:
quoted
On Tue, Jul 11, 2017 at 02:44:59PM -0300, Marcelo Henrique Cerri wrote:
quoted
Since v4.11-rc1~18^2~76, kill_pid() is declared in
"linux/sched/signal.h" instead of in "linux/sched.h".

Include the correct header file based on the kernel version to keep
it compatible with older kernels.

Signed-off-by: Marcelo Henrique Cerri <redacted>
When talking on irc to Sebastian we thought it a better idea to just
remove backfire. I patched if already in the past for the debian
packaging to build on 2.6.32 and 3.6 which were the versions available
in Debian back then. That also means that the patch in question here
isn't sufficient to make backfire build on 4.11. In fact it doesn't
compile since 2.6.39-rc1 when SPIN_LOCK_UNLOCKED was killed in
d04fa5a3ba06 ("locking: Remove deprecated lock initializers").

@John and Clark: Which branch do you want me to base a "remove bitrotten
backfire" patch on? IMHO there is a bit of chaos there because the v1.1
tag bases on v2.0 and has VERSION = 2.0 in Makefile. stable/v1.0
bases on v1.0, while unstable/devel/v1.1.1 bases on v1.1 and v1.1.1
seems to be its target version?

Best regards
Uwe
Hmmn, I find the idea of backfire kinda neat, my first instinct is to
say, why can't we fix this? If something is broken in the devel version
too, that's okay with me, you can disable that part if you want to
ship the devel version.
"neat" isn't IMHO enough to justify keeping that. If nobody is using it
and even nobody notices that it doesn't compile on kernels released in
the last 6 years ...
 
quoted
The naming chaos is my fault, it took my awhile to settle on naming
the devel version. However I wonder if something is wrong with your
local repo, because I thought I had cleaned that all up? I don't
see VERSION = 2.0 in the makefile for example.
It's not my local repo:

	uwe@taurus:~$ git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.gitCloning into 'rt-tests'...
	remote: Counting objects: 2917, done.
	remote: Total 2917 (delta 0), reused 0 (delta 0)
	Receiving objects: 100% (2917/2917), 739.04 KiB | 0 bytes/s, done.
	Resolving deltas: 100% (1898/1898), done.
	uwe@taurus:~$ cd rt-tests/
	uwe@taurus:~/rt-tests$ git show v1.1:Makefile | grep ^VERSION
	VERSION = 2.0
I fixed the above over a year ago

git show c8ce47ae170a
commit c8ce47ae170a2d6d1634ad948c56113ec8d64b64
Author: John Kacur [off-list ref]
Date:   Thu Jun 23 12:19:05 2016 +0200

    rt-tests: Makefile, change version to 1.1
    
    Rethinking the naming scheme, so changing the development line from 
2.0
    to 1.1
    
    Signed-off-by: John Kacur [off-list ref]
diff --git a/Makefile b/Makefile
index a54d82bd8964..d60282e05931 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-VERSION = 2.0
+VERSION = 1.1
 CC?=$(CROSS_COMPILE)gcc
 AR?=$(CROSS_COMPILE)ar
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help