trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Subsystems (2)
PATCH 1/1 trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Hi,
drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1 -1
@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC; } #endif
Yours,
Signature · 3 lines
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45drivers/md/raid6altivec.uc line 111
Quoted 13 lines · Rene Rebe
Hi,
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1
-1@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
I nominate this as a candidate for linux-2.6.11 release branch. :)
Jeff
Quoted 4 lines · Jeff Garzik
Quoted 3 lines · Rene Rebe
Hi,
Quoted 13 lines
drivers/md/raid6altivec.uc line 111
Quoted 10 lines
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1
-1@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;I nominate this as a candidate for linux-2.6.11 release branch. :)
Except the patch is malformed, and even after light editing, does not apply to the 2.6.11 kernel :(
thanks,
greg k-h
Hi,
Quoted 2 lines · Greg KH
Except the patch is malformed, and even after light editing, does not apply to the 2.6.11 kernel :(
Sorry - to match linux-kernel style I pasted it from gvim into thunderbird to make kernel folks happy. Here you find the patch as it applies to 2.6.11 attached.
Yours,
Signature · 3 lines
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45Tiny compile fix for the raid6 PowerPC/Altivec code.
- Rene Rebe <[email protected]>
drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1 -1
@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC; } #endif
Quoted 4 lines · Jeff Garzik
Quoted 3 lines · Rene Rebe
Hi,
Quoted 13 lines
drivers/md/raid6altivec.uc line 111
Quoted 10 lines
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1
-1@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;I nominate this as a candidate for linux-2.6.11 release branch. :)
Ok, I've fixed up the patch and applied it to a local tree that I've set up to catch these things (it will live at bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I set up how we are going to handle all of this.)
Feel free to start pointing stuff like this at me and chris (we'll also be setting up an alias for it.)
thanks,
greg k-h
Greg KH wrote:
Two procedural suggestions...
Quoted 4 lines
Ok, I've fixed up the patch and applied it to a local tree that I've set up to catch these things (it will live at bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I set up how we are going to handle all of this.)
My suggestion would be one of two alternatives:
1) At each release, Linus clones
linux.bkbits.net/linux-2.6 to linux.bkbits.net/linux-2.6.11
and gives the "release team" access to push to linux-2.6.11 repo.
2) Create linux-release.bkbits.net, and some non-Linus person clones linux-2.6 at release time to linux-2.6.11.
This accomplishes two [minor] goals:
a) the tree lives at bkbits.net, as has a name associated with the goal of the project
b) The repo has the _exact_ name of the kernel release. None of this "linux-2.6.11.y" stuff. Just "linux-2.6.11". Anything else violates the Principle of Least Surprise.
Quoted 2 lines
Feel free to start pointing stuff like this at me and chris (we'll also be setting up an alias for it.)
I was wondering if it would be possible to setup a list on vger that is public, but read-only to everyone but the $sucker team.
Jeff
Quoted 9 lines · * Jeff Garzik ([email protected]) wrote:
Greg KH wrote:
Two procedural suggestions...
Quoted 4 lines
Ok, I've fixed up the patch and applied it to a local tree that I've set up to catch these things (it will live at bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I set up how we are going to handle all of this.)
Quoted 8 lines
My suggestion would be one of two alternatives:
1) At each release, Linus clones
linux.bkbits.net/linux-2.6 to linux.bkbits.net/linux-2.6.11and gives the "release team" access to push to linux-2.6.11 repo.
My recollection of the bkbits interface is that it's keys are good for a "project" dir. So I don't know if it would work like you suggested.
Quoted 2 lines
2) Create linux-release.bkbits.net, and some non-Linus person clones linux-2.6 at release time to linux-2.6.11.
This is closer to what I suggested to Greg (although I like your name better).
Quoted 9 lines
This accomplishes two [minor] goals:
a) the tree lives at bkbits.net, as has a name associated with the goal of the projectb) The repo has the _exact_ name of the kernel release. None of this "linux-2.6.11.y" stuff. Just "linux-2.6.11". Anything else violates the Principle of Least Surprise.
Quoted 5 lines
Quoted 2 lines
Feel free to start pointing stuff like this at me and chris (we'll also be setting up an alias for it.)
I was wondering if it would be possible to setup a list on vger that is public, but read-only to everyone but the $sucker team.
Don't see why not, we were thinking of making it just an alias at kernel.org.
thanks,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Quoted 19 lines · Chris Wright
Quoted 9 lines · * Jeff Garzik ([email protected]) wrote:
Greg KH wrote:
Two procedural suggestions...
Quoted 4 lines
Ok, I've fixed up the patch and applied it to a local tree that I've set up to catch these things (it will live at bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I set up how we are going to handle all of this.)
Quoted 8 lines
My suggestion would be one of two alternatives:
1) At each release, Linus clones
linux.bkbits.net/linux-2.6 to linux.bkbits.net/linux-2.6.11and gives the "release team" access to push to linux-2.6.11 repo.
Quoted 8 lines
My recollection of the bkbits interface is that it's keys are good for a "project" dir. So I don't know if it would work like you suggested.
Quoted 2 lines
2) Create linux-release.bkbits.net, and some non-Linus person clones linux-2.6 at release time to linux-2.6.11.
This is closer to what I suggested to Greg (although I like your name better).
I like this too, less work for Linus to do this.
Ok, linux-release.bkbits.net is now created.
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Feel free to start pointing stuff like this at me and chris (we'll also be setting up an alias for it.)
I was wondering if it would be possible to setup a list on vger that is public, but read-only to everyone but the $sucker team.
So, the $sucker team can't read it, but the rest of the world could? :)
Quoted 2 lines
Don't see why not, we were thinking of making it just an alias at kernel.org.
An alias would probably be easier, unless you think everything sent there should be archived?
thanks,
greg k-h
Quoted 7 lines · Greg KH
Quoted 2 lines · Chris Wright
Don't see why not, we were thinking of making it just an alias at kernel.org.
An alias would probably be easier, unless you think everything sent there should be archived?
I do. But I don't have a strong opinion on the subject.
Jeff
Jeff Garzik <[email protected]> :
Quoted 1 line
Greg KH wrote:
[...]
Quoted 4 lines
Quoted 2 lines
An alias would probably be easier, unless you think everything sent there should be archived?
I do. But I don't have a strong opinion on the subject.
A bk-commit mailing-list would be nice.
--
Ueimor
Quoted 4 lines · Jeff Garzik
Quoted 3 lines · Rene Rebe
Hi,
Quoted 13 lines
drivers/md/raid6altivec.uc line 111
Quoted 10 lines
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1
-1@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;I nominate this as a candidate for linux-2.6.11 release branch. :)
No. Unfortunately if you fix ppc64 here you will break ppc, and vice versa. Yes, we are going to reconcile the cur_cpu_spec definitions between ppc and ppc64. :)
Paul.
Quoted 19 lines · Paul Mackerras
Quoted 4 lines · Jeff Garzik
Quoted 3 lines · Rene Rebe
Hi,
Quoted 13 lines
drivers/md/raid6altivec.uc line 111
Quoted 10 lines
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1
-1@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;I nominate this as a candidate for linux-2.6.11 release branch. :)
Quoted 3 lines
No. Unfortunately if you fix ppc64 here you will break ppc, and vice versa. Yes, we are going to reconcile the
cur_cpu_specdefinitions between ppc and ppc64. :)
Fine, dueling arches, who wins? :)
So, what do I do, just ignore the patch? Or do you have a fix?
thanks,
greg k-h
Quoted 20 lines · Greg KH
Quoted 19 lines · Paul Mackerras
Quoted 17 lines · Jeff Garzik
drivers/md/raid6altivec.uc line 111
Quoted 13 lines · Rene Rebe
Hi,
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02
16:45:22.424152560 +0100drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc.vanilla +1
-1@@ -108,7 +108,7 @@ int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ - return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;I nominate this as a candidate for linux-2.6.11 release branch. :)
Quoted 7 lines
Quoted 3 lines
No. Unfortunately if you fix ppc64 here you will break ppc, and vice versa. Yes, we are going to reconcile the
cur_cpu_specdefinitions between ppc and ppc64. :)Fine, dueling arches, who wins? :)
So, what do I do, just ignore the patch? Or do you have a fix?
until its fixed properly, how about this ?
+#ifdef CONFIG_PPC64
return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#else
+ return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#endif
Brings about an interesting conundrum with teh 2.6.x.y branch. If fixing something properly is invasive, would we want to allow band-aids to get things working ? This would make things more difficult wrt Linus being able to pull the previous .y branch into his current tree, but bitkeepers conflict resolution is really unsurpassed for such situations in my experience.
Dave
Quoted 5 lines · Paul Mackerras
Quoted 1 line
I nominate this as a candidate for linux-2.6.11 release branch. :)
No. Unfortunately if you fix ppc64 here you will break ppc, and vice versa. Yes, we are going to reconcile the
cur_cpu_specdefinitions between ppc and ppc64. :)
The proper fix is to get the cpu_has_feature patch merged up from -mm, but that's 99% cleanup and 1% bugfix. So here's a more appropriate fix for the 2.6.11 patch stream. This goes on top of the one that just got merged there.
-Olof
---
Here's a patch that will work for both PPC and PPC64. The proper way to fix this in mainline is to merge -mm's cpu_has_feature patch, but for the stable 2.6.11-series, this much less intrusive (i.e. just the pure bugfix, not the cleanup part).
drivers/md/raid6altivec.uc +4 -0
@@ -108,7 +108,11 @@ int raid6_have_altivec(void); int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ +#ifdef CONFIG_PPC64 + return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; +#else return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC; +#endif } #endif
Greg KH
AppliedQuoted 11 lines · Olof Johansson
Quoted 5 lines · Paul Mackerras
Quoted 1 line
I nominate this as a candidate for linux-2.6.11 release branch. :)
No. Unfortunately if you fix ppc64 here you will break ppc, and vice versa. Yes, we are going to reconcile the
cur_cpu_specdefinitions between ppc and ppc64. :)The proper fix is to get the
cpu_has_featurepatch merged up from -mm, but that's 99% cleanup and 1% bugfix. So here's a more appropriate fix for the 2.6.11 patch stream. This goes on top of the one that just got merged there.
Applied, thanks.
greg k-h
Quoted 9 lines · [email protected] (Olof Johansson) wrote:
Here's a patch that will work for both PPC and PPC64. The proper way to
fix this in mainline is to merge -mm'scpu_has_featurepatch, but for the stable 2.6.11-series, this much less intrusive (i.e. just the pure bugfix, not the cleanup part).Signed-off-by Olof Johansson <[email protected]>
Quoted 15 lines
Index: linux-2.5/drivers/md/raid6altivec.uc
===================================================================
--- linux-2.5.orig/drivers/md/raid6altivec.uc 2005-03-03 16:46:47.000000000 -0600
+++ linux-2.5/drivers/md/raid6altivec.uc 2005-03-03 16:48:03.000000000 -0600
@@ -108,7 +108,11 @@ intraid6_have_altivec(void);
intraid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
+#ifdefCONFIG_PPC64
+ returncur_cpu_spec->cpu_features&CPU_FTR_ALTIVEC;
+#else
return cur_cpu_spec[0]->cpu_features &CPU_FTR_ALTIVEC;
+#endif
}
#endif
This patch doesn't seem right - current 2.6.11 has:
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
So anyway, I fixed it up as:
drivers/md/raid6altivec.uc renamed from drivers/md/raid6altivec.uc~ppc-raid6-altivec-build-fix +4 -0
@@ -108,7 +108,11 @@ int raid6_have_altivec(void); int raid6_have_altivec(void) { /* This assumes either all CPUs have Altivec or none does */ +#ifdef CONFIG_PPC64 return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; +#else + return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC; +#endif } #endif
_
I'll assume that the above is suitable as a temp thing and I'll fix up ppc-ppc64-abstract-cpu_feature-checks.patch
Hi,
Quoted 3 lines · Andrew Morton
This patch doesn't seem right - current 2.6.11 has:
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
The patch was against what Greg had already pushed into the linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. You're right, your revised patch would apply against mainline.
However: This patch shouldn't go to mainline, since ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of the problem. I'd like the abstraction/cleanup patch to be merged upstream instead of the #ifdef hack once the tree opens up.
Thanks,
-Olof
Quoted 7 lines · * Olof Johansson ([email protected]) wrote:
Hi,
Quoted 3 lines · Andrew Morton
This patch doesn't seem right - current 2.6.11 has:
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
Quoted 8 lines
The patch was against what Greg had already pushed into the linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. You're right, your revised patch would apply against mainline.
However: This patch shouldn't go to mainline, since ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of the problem. I'd like the abstraction/cleanup patch to be merged upstream instead of the #ifdef hack once the tree opens up.
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
thanks,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Quoted 20 lines · Chris Wright
Quoted 8 lines · * Olof Johansson ([email protected]) wrote:
Hi,
Quoted 3 lines · Andrew Morton
This patch doesn't seem right - current 2.6.11 has:
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;Quoted 8 lines
The patch was against what Greg had already pushed into the linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. You're right, your revised patch would apply against mainline.
However: This patch shouldn't go to mainline, since ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of the problem. I'd like the abstraction/cleanup patch to be merged upstream instead of the #ifdef hack once the tree opens up.
Quoted 4 lines
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
Just need to make sure <whomever> aware of this, when you push to Linus.
In most cases, of dire fixes, they should just go into linux-release, and then get pulled into linux-2.6.
For a few cases, like this one, the quick fix will hit linux-release and linux-2.6 before the better fix, so no big deal.
In a few rare cases, you will need to create a "for-upstream" tree that handles the conflict before it get pushed to Linus.
Jeff
Quoted 8 lines · Jeff Garzik
Quoted 5 lines
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
Just need to make sure <whomever> aware of this, when you push to Linus.
Quoted 8 lines
In most cases, of dire fixes, they should just go into linux-release, and then get pulled into linux-2.6.
For a few cases, like this one, the quick fix will hit linux-release and linux-2.6 before the better fix, so no big deal.
In a few rare cases, you will need to create a "for-upstream" tree that handles the conflict before it get pushed to Linus.
As I say, it sounds dumb, but I'm sure you can make it work ;)
The main person it affects is yours truly:
bix:/usr/src/25> grep fix series | wc -l
162
And fixes which are 2.6.x.y material need to go mm->linux_release->linus. I drop them when they turn up in Linus's tree.
That works as long as I don't have non-linux_release patches which depend upon earlier fixes. If that happens I have to wait until linux-release merges up.
Again, it's manageable, but complex.
Quoted 3 lines · Andrew Morton
That works as long as I don't have non-linux_release patches which depend upon earlier fixes. If that happens I have to wait until linux-release merges up.
Hopefully linux-release pulls, and linux-release releases, will happen fairly quickly. Otherwise its value diminishes.
Release early, release often </chant>
Jeff
Quoted 18 lines · Chris Wright
Quoted 7 lines · * Olof Johansson ([email protected]) wrote:
Hi,
Quoted 3 lines · Andrew Morton
This patch doesn't seem right - current 2.6.11 has:
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;Quoted 8 lines
The patch was against what Greg had already pushed into the linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. You're right, your revised patch would apply against mainline.
However: This patch shouldn't go to mainline, since ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of the problem. I'd like the abstraction/cleanup patch to be merged upstream instead of the #ifdef hack once the tree opens up.
Quoted 4 lines
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
It depends who gets to Linus's tree first. If linux-release merges first, I just revert the temp fix while adding the real fix. But the temp fix should never have gone into Linus's tree in the first place.
If I merge before linux-release, I guess Linus has some conflict resolving to do when he pulls from linux-release. That's OK for an obvious two-liner, but would get out of control for more substantial things.
Neither solution is acceptable, really. I suspect the idea of pulling linux-release into mainline won't work very well, and that making it a backport tree would be more practical.
Quoted 31 lines · Andrew Morton
Quoted 19 lines · Chris Wright
Quoted 8 lines · * Olof Johansson ([email protected]) wrote:
Hi,
Quoted 3 lines · Andrew Morton
This patch doesn't seem right - current 2.6.11 has:
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;Quoted 8 lines
The patch was against what Greg had already pushed into the linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. You're right, your revised patch would apply against mainline.
However: This patch shouldn't go to mainline, since ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of the problem. I'd like the abstraction/cleanup patch to be merged upstream instead of the #ifdef hack once the tree opens up.
Quoted 4 lines
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
It depends who gets to Linus's tree first. If linux-release merges first, I just revert the temp fix while adding the real fix. But the temp fix should never have gone into Linus's tree in the first place.
Quoted 7 lines
If I merge before linux-release, I guess Linus has some conflict resolving to do when he pulls from linux-release. That's OK for an obvious two-liner, but would get out of control for more substantial things.
Neither solution is acceptable, really. I suspect the idea of pulling linux-release into mainline won't work very well, and that making it a backport tree would be more practical.
Maybe you're right, but I tend to think that "quick, get that fix out immediately" fixes will appear before more substantial fixes. That is certainly the way things have worked up until now.
For the cases that we care about, putting that into linux-release and then pulling would seem more appropriate.
Remember, the linux-release tree for each release will slow down, and eventually die off, as we progress towards the next release (where the linux-2.6.x.y-1 tree will indeed die).
Jeff
Quoted 10 lines · * Jeff Garzik ([email protected]) wrote:
Quoted 9 lines · Andrew Morton
Quoted 4 lines · Chris Wright
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
It depends who gets to Linus's tree first. If linux-release merges first, I just revert the temp fix while adding the real fix. But the temp fix should never have gone into Linus's tree in the first place.
Consider it first patch in fixup series ;-)
Quoted 8 lines
Quoted 7 lines
If I merge before linux-release, I guess Linus has some conflict resolving to do when he pulls from linux-release. That's OK for an obvious two-liner, but would get out of control for more substantial things.
Neither solution is acceptable, really. I suspect the idea of pulling linux-release into mainline won't work very well, and that making it a backport tree would be more practical.
Quoted 6 lines
Maybe you're right, but I tend to think that "quick, get that fix out immediately" fixes will appear before more substantial fixes. That is certainly the way things have worked up until now.
For the cases that we care about, putting that into linux-release and then pulling would seem more appropriate.
Yes, and this case was on the border of a newly existing system.
thanks,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Quoted 9 lines · Chris Wright
Quoted 7 lines · * Jeff Garzik ([email protected]) wrote:
Quoted 6 lines · Andrew Morton
Quoted 4 lines · Chris Wright
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
It depends who gets to Linus's tree first. If linux-release merges first, I just revert the temp fix while adding the real fix. But the temp fix should never have gone into Linus's tree in the first place.
Consider it first patch in fixup series ;-)
Here's the second, and this is much more critical.
And it's untested.
And it's a temp-fix - it'll be addressed by other means in 2.6.12.
What do we do?
From: Dmitry Torokhov <[email protected]>
Some ACPI-related changes were recently made to i8042 discovery for ia64. Unfortunately this broke a significant number of Dell laptops due to their having incorrect BIOS tables.
So, for now, arrange for the new code to be ia64-only.
---
25-akpm/drivers/input/serio/i8042-x86ia64io.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
drivers/input/serio/i8042-x86ia64io.h renamed from drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround +3 -3
@@ -88,7 +88,7 @@ static struct dmi_system_id __initdata i };#endif -#ifdef CONFIG_ACPI +#if defined(__ia64__) && defined(CONFIG_ACPI )#include <linux/acpi.h> #include <acpi/acpi_bus.h>
@@ -281,7 +281,7 @@ static inline int i8042_platform_init(vo i8042_kbd_irq =I8042_MAP_IRQ (1 ); i8042_aux_irq =I8042_MAP_IRQ (12 ); -#ifdef CONFIG_ACPI +#if defined(__ia64__) && defined(CONFIG_ACPI )if (i8042_acpi_init ())return -1 ;#endif
@@ -300,7 +300,7 @@ static inline int i8042_platform_init(vostatic inline void i8042_platform_exit (void ) { -#ifdef CONFIG_ACPI +#if defined(__ia64__) && defined(CONFIG_ACPI )i8042_acpi_exit ();#endif }
_
Quoted 10 lines · * Andrew Morton ([email protected]) wrote:
Quoted 9 lines · Chris Wright
Quoted 7 lines · * Jeff Garzik ([email protected]) wrote:
Quoted 6 lines · Andrew Morton
Quoted 4 lines · Chris Wright
Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree?
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
It depends who gets to Linus's tree first. If linux-release merges first, I just revert the temp fix while adding the real fix. But the temp fix should never have gone into Linus's tree in the first place.
Consider it first patch in fixup series ;-)
Actually I meant fix 1/2 == quick, fix 2/2 == more complete.
Quoted 3 lines
Here's the second, and this is much more critical.
And it's untested.
I'd rather it be tested.../me keeps wishing
If it's untested, are we even sure it fixes the problem? Or are you worried about the umpteen other non-Dell laptops that could have problems with the patch?
Quoted 3 lines
And it's a temp-fix - it'll be addressed by other means in 2.6.12.
What do we do?
IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke laptops how)? Can it be worked around with the i8042.noacpi boot param? If so, I don't think it fits the bill as critical.
thanks,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Quoted 8 lines · Chris Wright
Quoted 4 lines
And it's a temp-fix - it'll be addressed by other means in 2.6.12.
What do we do?
IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke laptops how)? Can it be worked around with the i8042.noacpi boot param? If so, I don't think it fits the bill as critical.
Well. It was critical for 2.6.11, but it didn't make it :(
So people whose keyboards don't work need to either update to 2.6.11.1 or add i8042.noacpi=1. <rekicks self>
But it's just a for-instance.
Quoted 11 lines · * Andrew Morton ([email protected]) wrote:
Quoted 8 lines · Chris Wright
Quoted 4 lines
And it's a temp-fix - it'll be addressed by other means in 2.6.12.
What do we do?
IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke laptops how)? Can it be worked around with the i8042.noacpi boot param? If so, I don't think it fits the bill as critical.
Well. It was critical for 2.6.11, but it didn't make it :(
Ah, I see.
Quoted 4 lines
So people whose keyboards don't work need to either update to 2.6.11.1 or add i8042.noacpi=1. <rekicks self>
But it's just a for-instance.
And a good one to exercise the rules measuring how critical the patch is. In this case, I don't think it is if workaround is good enough, but could be convinced if Dmitry thinks otherwise.
Anyway, time to pack, sleep a few and catch a plane back west later,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Quoted 3 lines · Chris Wright
IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke laptops how)? Can it be worked around with the i8042.noacpi boot param? If so, I don't think it fits the bill as critical.
If it was critical for 2.6.11, I would think it's critical for 2.6.11.1.
One would hope its at least tested on one affected laptop.
The boot param is rather lame, IMO, since it affects a -bunch- of laptops. But whatever...
Jeff
Quoted 3 lines · Jeff Garzik
The boot param is rather lame, IMO, since it affects a -bunch- of
laptops. But whatever...
My main desktop (a recent Dell), running 2.6.11-rc4-mm1 needs i8042.nopnp=1 (sic. It got renamed) so I can type stuff too. (rerekicks self). I expect this machine would require i8042.noacpi=1 if it was running 2.6.11.
Lots of machines are affected. It's a bit of a howler.
Quoted 10 lines · Andrew Morton
Quoted 1 line · Jeff Garzik
The boot param is rather lame, IMO, since it affects a -bunch- of laptops. But whatever...
My main desktop (a recent Dell), running 2.6.11-rc4-mm1 needs i8042.nopnp=1 (sic. It got renamed) so I can type stuff too. (rerekicks self). I expect this machine would require i8042.noacpi=1 if it was running 2.6.11.
Lots of machines are affected. It's a bit of a howler.
Definitely a linux-release candidate then.
On a side note, it would be nice to give you access to push things into the linux-release tree yourself.
Jeff
Quoted 9 lines · Andrew Morton
From: Dmitry Torokhov <[email protected]>
Some ACPI-related changes were recently made to i8042 discovery for ia64. Unfortunately this broke a significant number of Dell laptops due to their having incorrect BIOS tables.
So, for now, arrange for the new code to be ia64-only.
Signed-off-by Andrew Morton <[email protected]>
Ok, based on consensus, I've applied this one too.
Yes, we will get a bk-stable-commits tree up and running, still working out the infrastructure...
thanks,
greg k-h
Quoted 2 lines · Greg KH
Ok, based on consensus, I've applied this one too.
Btw, I don't think your process works. You never really gave people the time to object. So for that reason you applied the first trivial raid6 thing, and it turned out to be wrong.
I think the patches need to have a rule like "they live outside the sucker tree for at least two days". And during that time, anybody can vote them down (which would move them to "unapplied" status, at which point somebody else might decide that for _their_ tree it's still the right thing to do).
And if at the end of two days, they still haven't gotten enough "yes" votes, they'd go into "limbo" status, with one extra grace-period (ie a reminder on whatever list about a patch that is dying). And if it can't get enough "yeah, sure" votes even after that, it goes into the same "unapplied" list.
In other words, I think this really does want some automation. It shouldn't be fully automated (at the very least, somebody needs to actually check that things patch and fix up the changeset comments etc), but the _rules_ should be automated. Otherwise they'll always be broken because of "_this_ time it's obvious", which is against the point.
Linus
Quoted 9 lines · Linus Torvalds
Quoted 2 lines · Greg KH
Ok, based on consensus, I've applied this one too.
Btw, I don't think your process works. You never really gave people the time to object. So for that reason you applied the first trivial raid6 thing, and it turned out to be wrong.
I agree.
Quoted 11 lines
I think the patches need to have a rule like "they live outside the sucker tree for at least two days". And during that time, anybody can vote them down (which would move them to "unapplied" status, at which point somebody else might decide that for _their_ tree it's still the right thing to do).
And if at the end of two days, they still haven't gotten enough "yes" votes, they'd go into "limbo" status, with one extra grace-period (ie a reminder on whatever list about a patch that is dying). And if it can't get enough "yeah, sure" votes even after that, it goes into the same "unapplied" list.
Quoted 5 lines
In other words, I think this really does want some automation. It shouldn't be fully automated (at the very least, somebody needs to actually check that things patch and fix up the changeset comments etc), but the _rules_ should be automated. Otherwise they'll always be broken because of "_this_ time it's obvious", which is against the point.
Ok, Chris and I are going to sit down and work this all out on Tuesday. I'll hold off on applying or releasing anything else until we fully describe the process, and set up the infrastructure.
I'll slow down now :)
thanks,
greg k-h
Quoted 4 lines · Greg KH
Ok, based on consensus, I've applied this one too.
Yes, we will get a bk-stable-commits tree up and running, still working out the infrastructure...
Cool. Once you've done so make sure there are also no bk snapshots and I'll push you some of the tiny but critical fixes (security, non working ULI tulip etc) from 11-ac1 when I upload it.
Alan
Quoted 1 line · Alan Cox
Cool. Once you've done so make sure there are also no bk snapshots and
That should have read "non bk" snapshots before Larry goes boom 8)
Quoted 9 lines · Jeff Garzik
Quoted 4 lines
Neither solution is acceptable, really. I suspect the idea of pulling linux-release into mainline won't work very well, and that making it a backport tree would be more practical.
Maybe you're right, but I tend to think that "quick, get that fix out immediately" fixes will appear before more substantial fixes. That is certainly the way things have worked up until now.
Quoted 6 lines
For the cases that we care about, putting that into linux-release and then pulling would seem more appropriate.
Remember, the linux-release tree for each release will slow down, and eventually die off, as we progress towards the next release (where the linux-2.6.x.y-1 tree will indeed die).
Yup. But anyway, there's no point in overdesigning all this. Let's suck it and see. If it doesn't work we can populate linux-release by some other means. The downstream users of linux-release won't see any change as a result of that.