Re: [liblockdep] Re: [PATCH v2 01/11] liblockdep: remove the need for liblockdep_init

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

On 02/19/2013 02:58 AM, Ingo Molnar wrote:
> 
> * Sasha Levin <sasha.levin@oracle.com> wrote:
> 
>> Use a constructor in the library instead of making the user manually
>> call liblockdep_init().
>>
>> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>> ---
>>  tools/lib/lockdep/common.c                    | 2 +-
>>  tools/lib/lockdep/include/liblockdep/common.h | 1 -
>>  tools/lib/lockdep/tests/AA.c                  | 1 -
>>  tools/lib/lockdep/tests/ABBA.c                | 1 -
>>  tools/lib/lockdep/tests/ABBCCA.c              | 1 -
>>  tools/lib/lockdep/tests/ABBCCDDA.c            | 1 -
>>  tools/lib/lockdep/tests/ABCABC.c              | 1 -
>>  tools/lib/lockdep/tests/ABCDBCDA.c            | 1 -
>>  tools/lib/lockdep/tests/ABCDBDDA.c            | 1 -
>>  tools/lib/lockdep/tests/WW.c                  | 1 -
>>  tools/lib/lockdep/tests/unlock_balance.c      | 1 -
>>  tools/lib/lockdep/uinclude/linux/lockdep.h    | 1 -
>>  12 files changed, 1 insertion(+), 12 deletions(-)
> 
> Note that due to the heavy objections in the kvmtool thread I 
> have removed the tools/lib/lockdep library and tooling commits 
> from the locking tree - to be able to merge the other locking 
> commits upstream.

Understood.

> I'm pretty sad about this outcome as your code really brought 
> new development life into lockdep - if you still want to pursue 
> this approach then you might want to try it via the tools/kvm 
> tree, or via a separate project.

I'm most likely to just fold it into a standalone project since
I'm not quite certain the purpose of tools/ at this point.


Thanks,
Sasha