Skip to content
Snippets Groups Projects
  1. Dec 17, 2021
  2. Dec 11, 2021
  3. Dec 09, 2021
  4. Dec 08, 2021
  5. Dec 07, 2021
  6. Dec 03, 2021
  7. Nov 30, 2021
  8. Nov 25, 2021
  9. Nov 24, 2021
  10. Nov 22, 2021
  11. Nov 19, 2021
  12. Nov 18, 2021
  13. Nov 17, 2021
  14. Nov 12, 2021
    • 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
  15. Nov 09, 2021
  16. Nov 06, 2021
  17. Nov 05, 2021
  18. Nov 04, 2021
  19. Nov 03, 2021
  20. Nov 01, 2021
  21. Oct 30, 2021
  22. Oct 29, 2021
  23. Oct 28, 2021
Loading