Skip to content
Snippets Groups Projects
  1. Apr 19, 2022
  2. Jan 03, 2022
  3. Dec 25, 2021
  4. Dec 17, 2021
  5. Dec 11, 2021
  6. Dec 09, 2021
  7. Dec 08, 2021
  8. Dec 07, 2021
  9. Dec 06, 2021
  10. Dec 03, 2021
  11. Nov 30, 2021
  12. Nov 25, 2021
  13. Nov 24, 2021
  14. Nov 22, 2021
  15. Nov 19, 2021
  16. Nov 18, 2021
  17. Nov 17, 2021
  18. Nov 12, 2021
    • Karol Herbst's avatar
      MAINTAINERS: update information for nouveau · 94bdb32a
      Karol Herbst authored
      
      Some side notes on this. Atm we do want to use gitlab for bug tracking and
      merge requests. But due to the nature of the current linux kernel
      development, we can only do so for nouveau internal changes.
      
      Everything else still needs to be sent as emails and this is also includes
      changes to UAPI etc.
      
      Anyway, if somebody wants to submit patches via gitlab, they are free to
      do so and this should just make this more official and documented.
      
      People listed as maintainers are such that have push access to drm-misc
      (where changes are pushed to after landing in gitlab) and are known
      nouveau developers.
      We did this already for some trivial changes and critical bug fixes
      already, we just weren't thinking about updating the MAINTAINERS file.
      
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: dri-devel@lists.freedesktop.org
      Cc: nouveau@lists.freedesktop.org
      Signed-off-by: Karol Herbst's avatarKarol Herbst <kherbst@redhat.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20211110133157.553251-1-kherbst@redhat.com
      94bdb32a
    • 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
  19. Nov 09, 2021
  20. Nov 06, 2021
  21. Nov 05, 2021
  22. Nov 04, 2021
  23. Nov 03, 2021
  24. Nov 01, 2021
Loading