On Tue, Feb 10, 2015 at 09:25:26AM -0800, Paul E. McKenney wrote: > On Tue, Feb 10, 2015 at 11:48:37AM -0500, Rik van Riel wrote: > > On 02/10/2015 10:28 AM, Frederic Weisbecker wrote: > > > On Tue, Feb 10, 2015 at 09:41:45AM -0500, riel@xxxxxxxxxx wrote: > > >> From: Rik van Riel <riel@xxxxxxxxxx> > > >> > > >> These wrapper functions allow architecture code (eg. ARM) to keep > > >> calling context_tracking_user_enter & context_tracking_user_exit > > >> the same way it always has, without error prone tricks like duplicate > > >> defines of argument values in assembly code. > > >> > > >> Signed-off-by: Rik van Riel <riel@xxxxxxxxxx> > > > > > > This patch alone doesn't make much sense. > > > > Agreed, my goal was to keep things super easy to review, > > to reduce the chance of introducing bugs. > > > > > The changelog says it's about keeping > > > context_tracking_user_*() functions as wrappers but fails to explain to what they > > > wrap, why and what are the new context_tracking_enter/exit functions for. > > > > > > Perhaps patches 1 and 2 should be merged together into something like: > > > > > > context_tracking: Generalize context tracking APIs to support user and guest > > > > > > Do that because we'll also track guest....etc And keep the old user context tracking APIs > > > for now to avoid painful enum parameter support in ARM assembly.... > > > > Can do... > > > > Paul, would you like me to resend the whole series, or just > > a merged patch that replaces patches 1 & 2? > > I prefer the whole series, as it reduces my opportunity to introduce > human error when applying them. ;-) > > > That is assuming Paul prefers having the patches merged into > > one :) > > I am OK with that. I will merge the next set with the first two patches > merged, people have had sufficient opportunity to review. BTW, I have a few patches to make on the next cycle to fix a few context tracking related things. And since it's too late to push this series for the current merge window, now I wonder it may be easier if I take these patches. Otherwise you might experience unpleasant rebase conflicts. Is that ok for you? Thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
