trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

PATCH Applied Rene Rebe 11 participants 37 messages Mar 3, 2005 – Mar 7, 2005

Subsystems (2)

MD RAID Input drivers

lore

Share & tools

lore

Rene Rebe

author

2005-03-03 18:08 UTC #0 lore raw

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 45

Jeff Garzik

2005-03-03 18:29 UTC #1 lore raw

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 +0100
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;

I nominate this as a candidate for linux-2.6.11 release branch. :)

Jeff

Greg KH

2005-03-03 19:35 UTC #2 lore raw

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 +0100
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;
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

Jeff Garzik

2005-03-03 19:56 UTC #5 lore raw

In reply to Greg KH

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

Chris Wright

2005-03-03 20:13 UTC #6 lore raw

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.11
and 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 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 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

Greg KH

2005-03-03 20:38 UTC #7 lore raw

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.11
and 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

Jeff Garzik

2005-03-03 21:00 UTC #8 lore raw

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

Paul Mackerras

2005-03-03 22:36 UTC #10 lore raw

In reply to Jeff Garzik

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 +0100
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;
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.

Greg KH

2005-03-03 22:53 UTC #11 lore raw

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 +0100
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;
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_spec definitions 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

Olof Johansson

2005-03-03 23:02 UTC #13 lore raw

In reply to Paul Mackerras

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_spec definitions 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).

Signed-off-by Olof Johansson <[email protected]>

drivers/md/raid6altivec.uc +4 -0

Index: linux-2.5/drivers/md/raid6altivec.uc
===================================================================
@@ -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

Dave Jones

2005-03-03 23:16 UTC #12 lore raw

In reply to Greg KH

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 +0100
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;
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_spec definitions 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

Greg KH

Applied

2005-03-03 23:21 UTC #14 lore raw

In reply to Olof Johansson

Quoted 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_spec definitions 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.

Applied, thanks.

greg k-h

Andrew Morton

2005-03-04 02:04 UTC #15 lore raw

In reply to Olof Johansson

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'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).
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 @@ 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

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

Olof Johansson

2005-03-04 02:27 UTC #16 lore raw

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

Greg KH

2005-03-04 04:26 UTC #4 lore raw

In reply to Jeff Garzik

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 +0100
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;
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

Rene Rebe

author

2005-03-04 04:26 UTC #3 lore raw

In reply to Greg KH

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 45

Tiny 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

Chris Wright

2005-03-04 05:55 UTC #17 lore raw

In reply to Olof Johansson

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

Jeff Garzik

2005-03-04 06:06 UTC #18 lore raw

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

Andrew Morton

2005-03-04 06:07 UTC #21 lore raw

In reply to Chris Wright

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.

Jeff Garzik

2005-03-04 06:14 UTC #22 lore raw

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

Andrew Morton

2005-03-04 06:18 UTC #19 lore raw

In reply to Jeff Garzik

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

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.

Chris Wright

2005-03-04 06:20 UTC #23 lore raw

In reply to Jeff Garzik

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

Andrew Morton

2005-03-04 06:21 UTC #36 lore raw

In reply to Jeff Garzik

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.

Andrew Morton

2005-03-04 06:25 UTC #24 lore raw

In reply to Chris Wright

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.

Signed-off-by Andrew Morton <[email protected]>

---

 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

diff -puN drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround drivers/input/serio/i8042-x86ia64io.h
@@ -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(vo
 
 static inline void i8042_platform_exit(void)
 {
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
 	i8042_acpi_exit();
 #endif
 }

Jeff Garzik

2005-03-04 06:34 UTC #20 lore raw

In reply to Andrew Morton

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

Chris Wright

2005-03-04 06:49 UTC #25 lore raw

In reply to Andrew Morton

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

Andrew Morton

2005-03-04 06:55 UTC #26 lore raw

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.

Chris Wright

2005-03-04 07:04 UTC #27 lore raw

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

Jeff Garzik

2005-03-04 07:05 UTC #28 lore raw

In reply to Chris Wright

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

Andrew Morton

2005-03-04 07:15 UTC #29 lore raw

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.

Jeff Garzik

2005-03-04 07:17 UTC #30 lore raw

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

Francois Romieu

2005-03-04 12:26 UTC #9 lore raw

In reply to Jeff Garzik

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

Greg KH

2005-03-04 16:29 UTC #31 lore raw

In reply to Andrew Morton

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

Linus Torvalds

2005-03-04 18:41 UTC #32 lore raw

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

Greg KH

2005-03-04 18:59 UTC #33 lore raw

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

Alan Cox

2005-03-06 23:21 UTC #34 lore raw

In reply to Greg KH

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

Alan Cox

2005-03-07 18:05 UTC #35 lore raw

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)