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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/