[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150210172526.GQ4166@linux.vnet.ibm.com>
Date: Tue, 10 Feb 2015 09:25:26 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Rik van Riel <riel@...hat.com>
Cc: Frederic Weisbecker <fweisbec@...il.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 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.
Thanx, Paul
--
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