lkml.org 
[lkml]   [2013]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [liblockdep] Re: [PATCH v2 01/11] liblockdep: remove the need for liblockdep_init
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



\
 
 \ /
  Last update: 2013-02-20 16:44    [W:0.111 / U:1.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site