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:4.058 / U:0.328 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site