On 13/03/2018 10:22, Jan Beulich wrote: >>>> 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).
I'm sorry - I realise I'm very behind on reviews atm. If you've got the series rebased, then it will be easier to review this version than the old version. ~Andrew _______________________________________________ Xen-devel mailing list Xenemail@example.com https://lists.xenproject.org/mailman/listinfo/xen-devel