• Sasha Levin's avatar
    tools/lib/lockdep: drop liblockdep · 7246f4dc
    Sasha Levin authored
    TL;DR: While a tool like liblockdep is useful, it probably doesn't
    belong within the kernel tree.
    
    liblockdep attempts to reuse kernel code both directly (by directly
    building the kernel's lockdep code) as well as indirectly (by using
    sanitized headers). This makes liblockdep an integral part of the
    kernel.
    
    It also makes liblockdep quite unique: while other userspace code might
    use sanitized headers, it generally doesn't attempt to use kernel code
    directly which means that changes on the kernel side of things don't
    affect (and break) it directly.
    
    All our workflows and tooling around liblockdep don't support this
    uniqueness. Changes that go into the kernel code aren't validated to not
    break in-tree userspace code.
    
    liblockdep ended up being very fragile, breaking over and over, to the
    point that living in the same tree as the lockdep code lost most of it's
    value.
    
    liblockdep should continue living in an external tree, syncing with
    the kernel often, in a controllable way.
    Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    7246f4dc
MAINTAINERS 615 KB