Messages in this thread |  | | Date | Wed, 20 Feb 2013 10:05:12 -0500 | From | Sasha Levin <> | Subject | Re: [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
|  |