[ltt-dev] urcu library name-spacing

[ltt-dev] urcu library name-spacing

[Mathieu Desnoyers]

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)

Thanks,

Mathieu


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

[ltt-dev] urcu library name-spacing

[Paul E. McKenney]

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!

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

							Thanx, Paul

[ltt-dev] urcu library name-spacing

[Mathieu Desnoyers]

* 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

[ltt-dev] urcu library name-spacing

[David Goulet]

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