From mboxrd@z Thu Jan  1 00:00:00 1970
From: david.goulet@polymtl.ca (David Goulet)
Date: Sun, 14 Nov 2010 12:38:40 -0500
Subject: [ltt-dev] urcu library name-spacing
In-Reply-To: <20101114171802.GA15505@Krystal>
References: <20101114162937.GA773@Krystal>
	<20101114170252.GG2825@linux.vnet.ibm.com>
	<20101114171802.GA15505@Krystal>
Message-ID: <4CE01EA0.8080404@polymtl.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 10-11-14 12:18 PM, Mathieu Desnoyers wrote:
> * 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 ?

I just hope no name clash will happen again with this ulist_add and on..

I shall do that at the beginning of next week.

David

> 
>>
>> 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
> 
> 

- -- 
David Goulet
LTTng project, DORSAL Lab.

1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkzgHp8ACgkQSvfBSxa9hWNwpgCfegC8jCKLmfhK1VAgsdFnNxM5
1SgAn35x7DtKpU16nOhsMIjNoTea3tz+
=EBEQ
-----END PGP SIGNATURE-----