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
@@ -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,
--
Ren? Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
Rene Rebe wrote:
> 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
> @@ -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
On Thu, Mar 03, 2005 at 01:26:36PM -0500, Jeff Garzik wrote:
> Rene Rebe wrote:
> >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
> >@@ -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
Greg KH wrote:
Two procedural suggestions...
> 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.
> 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
* Jeff Garzik ([email protected]) wrote:
> Greg KH wrote:
>
> Two procedural suggestions...
>
> >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.
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.
> 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).
> 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.
>
>
> >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
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Greg KH wrote:
> On Thu, Mar 03, 2005 at 12:07:18PM -0800, Chris Wright wrote:
>>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
On Thu, Mar 03, 2005 at 12:07:18PM -0800, Chris Wright wrote:
> * Jeff Garzik ([email protected]) wrote:
> > Greg KH wrote:
> >
> > Two procedural suggestions...
> >
> > >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.
>
> 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.
>
> > 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.
> > >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? :)
> 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 writes:
> Rene Rebe wrote:
> > 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
> > @@ -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.
On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> Jeff Garzik writes:
> > Rene Rebe wrote:
> > > 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
> > > @@ -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. :)
Fine, dueling arches, who wins? :)
So, what do I do, just ignore the patch? Or do you have a fix?
thanks,
greg k-h
On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> > 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]>
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
On Thu, Mar 03, 2005 at 02:45:15PM -0800, Greg KH wrote:
> On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> > Jeff Garzik writes:
> > > Rene Rebe wrote:
> > > > 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
> > > > @@ -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. :)
>
> 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
On Thu, Mar 03, 2005 at 04:55:42PM -0600, Olof Johansson wrote:
> On Fri, Mar 04, 2005 at 09:30:22AM +1100, Paul Mackerras wrote:
> > > 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
[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]>
>
>
> 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:
--- 25/drivers/md/raid6altivec.uc~ppc-raid6-altivec-build-fix 2005-03-03 17:56:21.000000000 -0800
+++ 25-akpm/drivers/md/raid6altivec.uc 2005-03-03 17:57:50.000000000 -0800
@@ -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,
On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
> 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
Tiny compile fix for the raid6 PowerPC/Altivec code.
- Rene Rebe <[email protected]>
--- 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
@@ -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
On Thu, Mar 03, 2005 at 01:26:36PM -0500, Jeff Garzik wrote:
> Rene Rebe wrote:
> >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
> >@@ -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
* Olof Johansson ([email protected]) wrote:
> Hi,
>
> On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
> > 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.
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
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Chris Wright wrote:
> * Olof Johansson ([email protected]) wrote:
>
>>Hi,
>>
>>On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
>>
>>>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.
>
>
> 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
Chris Wright <[email protected]> wrote:
>
> * Olof Johansson ([email protected]) wrote:
> > Hi,
> >
> > On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
> > > 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.
>
> 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.
Andrew Morton wrote:
> Chris Wright <[email protected]> wrote:
>
>>* Olof Johansson ([email protected]) wrote:
>>
>>>Hi,
>>>
>>>On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote:
>>>
>>>>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.
>>
>>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.
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
Jeff Garzik <[email protected]> wrote:
>
> > 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.
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.
* Jeff Garzik ([email protected]) wrote:
> Andrew Morton wrote:
> >Chris Wright <[email protected]> wrote:
> >>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 ;-)
> >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.
Yes, and this case was on the border of a newly existing system.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Jeff Garzik <[email protected]> wrote:
>
> > 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).
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.
Chris Wright <[email protected]> wrote:
>
> * Jeff Garzik ([email protected]) wrote:
> > Andrew Morton wrote:
> > >Chris Wright <[email protected]> wrote:
> > >>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 ;-)
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(-)
diff -puN drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround drivers/input/serio/i8042-x86ia64io.h
--- 25/drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround 2005-03-03 13:34:49.000000000 -0800
+++ 25-akpm/drivers/input/serio/i8042-x86ia64io.h 2005-03-03 13:34:49.000000000 -0800
@@ -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
}
_
Andrew Morton wrote:
> 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
* Andrew Morton ([email protected]) wrote:
> Chris Wright <[email protected]> wrote:
> >
> > * Jeff Garzik ([email protected]) wrote:
> > > Andrew Morton wrote:
> > > >Chris Wright <[email protected]> wrote:
> > > >>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 ;-)
Actually I meant fix 1/2 == quick, fix 2/2 == more complete.
> 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?
> 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
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Chris Wright <[email protected]> wrote:
>
> > 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.
* Andrew Morton ([email protected]) wrote:
> Chris Wright <[email protected]> wrote:
> >
> > > 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.
> 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
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Chris Wright wrote:
> 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
Jeff Garzik <[email protected]> wrote:
>
> 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.
Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
>
>>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
Jeff Garzik <[email protected]> :
> Greg KH wrote:
[...]
> >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
On Thu, Mar 03, 2005 at 10:23:35PM -0800, Andrew Morton wrote:
> 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
On Fri, 4 Mar 2005, Greg KH wrote:
>
> 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
On Fri, Mar 04, 2005 at 10:38:10AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 4 Mar 2005, Greg KH wrote:
> >
> > 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.
> 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.
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
On Gwe, 2005-03-04 at 16:27, Greg KH wrote:
> 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
On Sul, 2005-03-06 at 23:06, Alan Cox wrote:
> 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)