Re: [PATCH 2/7] liblock: public headers for mutex implementation

[Sasha Levin <sasha.levin@oracle.com>]

On 02/01/2013 04:57 AM, Ingo Molnar wrote:
> 
> * Sasha Levin <sasha.levin@oracle.com> wrote:
> 
>> These headers provide the same API as their pthread mutex counterparts.
>>
>> The design here is to allow to easily switch to liblock lock validation
>> just by adding a "liblock_" to pthread_mutex_*() calls, which means that
>> it's easy to integrate liblock into existing codebases.
> 
> I'd suggest to name the user-space counterpart 'liblockdep', to 
> make it clear that this is user-space lockdep.

Agreed. Pekka also mentioned that liblock sounds to much like lib-block, so
renaming it to liblockdep will take care of that :)

> Regarding pthread_mutex_t checking, I think what we *really* 
> want is a wrapper that can be activated via:
> 
> #define __USE_LIBLOCKDEP
> 
> And which then takes over the pthread primitives via:
> 
>   #define pthread_mutex_lock liblockdep_pthread_mutex_lock
> 
> or so.
> 
> That way the source code only needs a __USE_LIBLOCKDEP in one or 
> two key places and checking is activated.

There are 2 issues I see with that:
 - api calls which are liblockdep specific (liblockdep_init() for example) would
still have to be wrapped somehow in the new code.
 - LIBLOCKDEP_PTHREAD_MUTEX_INIT(mtx) doesn't only change the name of the original
pthread mutex initializer, it also starts requiring the mutex name as parameter so
that it could pass it on to lockdep.

Dealing with these two will mean that there's a '#ifdef __USE_LIBLOCKDEP' both in
the lib and in the source code that uses it, which might be a bit confusing.

Either way, I'll resend the patch with these changes so we'll have a better view
of how it would look.


Thanks,
Sasha