diff options
| author | Sasha Levin <sashal@kernel.org> | 2021-11-12 10:16:02 -0500 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2021-11-12 11:07:17 -0800 |
| commit | 7246f4dcaccc8de76a96a41359d89c3c791579bc (patch) | |
| tree | 67a0bf0862f379884822698a8a104fb4bdbc77bf /MAINTAINERS | |
| parent | d9c8e52ff9e84ff1a406330f9ea4de7c5eb40282 (diff) | |
tools/lib/lockdep: drop liblockdep
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: Sasha Levin <sashal@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'MAINTAINERS')
| -rw-r--r-- | MAINTAINERS | 5 |
1 files changed, 0 insertions, 5 deletions
diff --git a/MAINTAINERS b/MAINTAINERS index ceba033023c3..a2fe76f56b32 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10799,11 +10799,6 @@ F: drivers/ata/ F: include/linux/ata.h F: include/linux/libata.h -LIBLOCKDEP -M: Sasha Levin <alexander.levin@microsoft.com> -S: Maintained -F: tools/lib/lockdep/ - LIBNVDIMM BLK: MMIO-APERTURE DRIVER M: Dan Williams <dan.j.williams@intel.com> M: Vishal Verma <vishal.l.verma@intel.com> |