>>> On 13.03.18 at 10:48, <jgr...@suse.com> wrote: > On 13/03/18 10:35, Jan Beulich wrote: >>>>> On 13.03.18 at 10:27, <jgr...@suse.com> wrote: >>> On 13/03/18 09:07, Jan Beulich wrote: >>>>>>> On 12.03.18 at 14:10, <jgr...@suse.com> wrote: >>>>> BTW: are you already working on rebasing your XPTI speed up series to >>>>> current staging? I'd like my series to use your series as a base unless >>>>> you are telling me you won't be able to resend your series soon. >>>> >>>> Coming back to my reply here yesterday - then again I'm a little >>>> reluctant to send out a new version that has no changes other >>>> than being re-based, when there were no comments by Andrew >>>> on most of the remaining patches yet (and in the one case >>>> where there were comments, I'm afraid I continue to disagree, >>>> but I'll see about moving that patch last in the series). >>> >>> In order to move forward, would you prefer me to base my patches on >>> current staging and put your patches on top of my series later? I just >>> don't want to rebase my series on a moving target... >> >> Well, I'm similarly not intending to re-base onto a series still under >> development / review. That's really the bad thing with deadlines: >> If we didn't freeze the tree at a given time, but at the point where >> previously agreed features and other non-bug-fix changes have >> landed, we wouldn't have such an ordering problem right now (or >> to be precise the ordering issue would still be there, but neither >> of us would be at risk of their changes not making it). > > Understandable. > > Could you then please repost at least patch 3? It has been approved > by Andrew and just needs the formal R-b: after rebasing.
Well, the thing with that patch is that from what I've been able to tell so far its re-basing will consist of dropping it, moving its sole remaining hunk (the altinstruction_nop assembler macro) into what has been patch 4. None of the uses of the macro in patch 3 should be needed anymore after Andrew's changes. Or actually I think the macro won't be needed as a standalone one anymore at all, as there's only a single place where it's used, and hence it would likely better be folded into there (the ALTERNATIVE_NOP one). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
