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

[John Kacur <jkacur@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3224 bytes --]



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:
> > On Wed, 12 Jul 2017, Uwe Kleine-König wrote:
> > > On Tue, Jul 11, 2017 at 02:44:59PM -0300, Marcelo Henrique Cerri wrote:
> > > > 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 <marcelo.cerri@canonical.com>
> > > 
> > > 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 ...
>  
> > 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 <jkacur@redhat.com>
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 <jkacur@redhat.com>

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