From mboxrd@z Thu Jan  1 00:00:00 1970
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Date: Sun, 14 Nov 2010 12:18:02 -0500
Subject: [ltt-dev] urcu library name-spacing
In-Reply-To: <20101114170252.GG2825@linux.vnet.ibm.com>
References: <20101114162937.GA773@Krystal>
	<20101114170252.GG2825@linux.vnet.ibm.com>
Message-ID: <20101114171802.GA15505@Krystal>

* Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> On Sun, Nov 14, 2010 at 11:29:37AM -0500, Mathieu Desnoyers wrote:
> > Hi Paul,
> > 
> > We're currently deploying UST (and thus urcu) into MariaDB (it's also deployed
> > in qemu), and it looks like there are some of our primitives that are causing
> > namespacing clash, e.g.
> > 
> > list_add
> > list_del
> > 
> > etc.
> > 
> > So I was wondering how we could proceed to change the namespace to something
> > that is not too confusing. Using a "rcu_" prefix is out of question, because it
> > would confuse "rcu-related" primitives (e.g. a primitive designed to be used in
> > a rcu read-side C.S. or update) with userspace-rcu-related primitives.
> > 
> > E.g., for list.h, we don't want to name these "rcu_list_add" if they are not
> > RCU-aware.
> > 
> > This would apply to other primitives, e.g.:
> > 
> > barrier()
> > smp_mb()
> > ....
> > 
> > So I would not want to use a prefix that is too long neither.
> > 
> > So far, for the atomic operations, I've simply done:
> > 
> > atomic_op() -> uatomic_op() (simply prepending a u). Do you think we could use
> > this technique for the rest ? (e.g. ulist_add, usmp_mb, etc)
> 
> Makes sense to me!

Good! So David, can you prepare the renaming to add the "u" prefix as needed ?

> 
> Of course, at some point, it might make sense to have the list primitives
> in a separate user-level library.

Yep. Although I'm already maintaining 3 separate packages. Seeing this number
grow even more makes me slightly uneasy. ;-) This is why, for now, it seems to
be a good idea to keep it simple and package the data structure headers in urcu.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com