[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150210173644.GB21917@lerouge>
Date: Tue, 10 Feb 2015 18:36:47 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Rik van Riel <riel@...hat.com>, will.deacon@....com,
linux-kernel@...r.kernel.org, Catalin.Marinas@....com,
kvm@...r.kernel.org, mtosatti@...hat.com, borntraeger@...ibm.com,
mingo@...nel.org, oleg@...hat.com, lcapitulino@...hat.com,
pbonzini@...hat.com
Subject: Re: [PATCH 1/6] rcu,nohz: add context_tracking_user_enter/exit
wrapper functions
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@...hat.com wrote:
> > >> From: Rik van Riel <riel@...hat.com>
> > >>
> > >> 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@...hat.com>
> > >
> > > 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists