* Sasha Levin <sasha.le...@oracle.com> wrote:
> Use a constructor in the library instead of making the user manually
> call liblockdep_init().
>
> Signed-off-by: Sasha Levin <sasha.le...@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.
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.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
