APPLIED: [2.6.32+drm33-longterm] Linux 188.8.131.52+drm33.19
stefan.bader at canonical.com
Thu Jul 14 15:35:24 UTC 2011
On 14.07.2011 17:24, Stefan Bader wrote:
> On 14.07.2011 17:11, Tim Gardner wrote:
>> On 07/14/2011 09:07 AM, Stefan Bader wrote:
>>> On 14.07.2011 14:51, Tim Gardner wrote:
>>> Seems, Tim, you just dropped the new xen patch. OK, I don't know
>>> exactly what the preference for stable is, but we may want to get
>>> back to be same as upstream...
>> Indeed I did as I saw no reason to revert the revert only to apply the revert
>> yet again.
>> I'm not sure I see the value in being the same as upstream stable. In fact,
>> we're not identical as soon as we revert _any_ patch that has arrived via stable.
> Though reverting the revert (which was reverting an upstream stable patch) would
> make the kernel be the same as upstream. And then adding the additional (partial
> revert) fixes the breakage. I agree it sounds confusing...
Ok, I don't think that helped much...
So the initial patch from upstream changed things affecting 32 and 64 bit in
order to fix a breakage caused by another patch (however that one was reverted
from upstream stable because it caused some other regression and has not been
re-applied yet (with the fix that fixed that regression).
The new xen patch is a partial revert in the sense that it changes the 32bit
code back to how it was before and preserves the change on the 64bit code path.
So as long as upstream does not decide that they want the patch that caused all
those fallout (x86: Cleanup highmap after brk is concluded), then we are ok with
the complete revert of the xen patch. But if they did, then the 64bit kernel
would fail under Xen. If we re-apply the patch we reverted and add the partial
revert, we would be ok in all cases.
More information about the kernel-team