Re: [PATCH] kernel: trace_syscalls: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Mon, Aug 25, 2014 at 07:05:54PM -0400, Steven Rostedt wrote:
> On Mon, 25 Aug 2014 15:56:54 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> 
> > > I guess I can add this. It's a very slow path thus it isn't critical.
> > > 
> > > Although, I hate the name. Perhaps we should add another macro called
> > > RCU_CLEAR_POINTER() or something that just nulls it. That way it
> > > documents the use. To me, INIT means the pointer is being initialized,
> > > where in reality it's just being cleared. I guess one could argue that
> > > the pointer is being "re-initialized".
> > 
> > I considered that, but there end up being three separate use cases
> > for this thing:
> > 
> > 1.	NULLing the pointer, as in this case.
> > 
> > 2.	Initializing the pointer at a time when no readers have a
> > 	reference to that pointer.  (In this case, there is presumably
> > 	a later rcu_assign_pointer() that makes the whole thing visible
> > 	to readers.)
> > 
> > 3.	Rearranging data that is already visible to readers, the usual
> > 	example being removing an element -- readers can already see
> > 	the successor in this case.
> > 
> > Having three different APIs for identical macros seemed like overkill
> > to me.  Especially given that people already complain about the RCU
> > API being too big.  :-(
> > 
> 
> Yeah, understood. But I think CLEAR is better than INIT as it says
> what it's doing more than what it is for. In all three above, we want
> to clear the pointer, but in only one case we want to initialize it.
> 
> But this is bikeshedding, and not worth the time of this dicussion.

PLAID!!!  We must paint the bikeshed plaid!

> No need to look further. Nothings going on here. Move along people or
> I'll have to get my pepper spray out.

;-) ;-) ;-)

							Thanx, Paul