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" <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
