APPLIED: [2.6.32+drm33-longterm] Linux 18.104.22.168+drm33.19
tim.gardner at canonical.com
Thu Jul 14 15:45:40 UTC 2011
On 07/14/2011 09:35 AM, Stefan Bader wrote:
> 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.
Egads! How about a pull request on top of master-next
51baad9488da20194cd457f5d7e4c07e77b0d988 that show the changes you think
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team