Kernel: Turn lock ranks into template parameters

This step would ideally not have been necessary (increases amount of
refactoring and templates necessary, which in turn increases build
times), but it gives us a couple of nice properties:
- SpinlockProtected inside Singleton (a very common combination) can now
  obtain any lock rank just via the template parameter. It was not
  previously possible to do this with SingletonInstanceCreator magic.
- SpinlockProtected's lock rank is now mandatory; this is the majority
  of cases and allows us to see where we're still missing proper ranks.
- The type already informs us what lock rank a lock has, which aids code
  readability and (possibly, if gdb cooperates) lock mismatch debugging.
- The rank of a lock can no longer be dynamic, which is not something we
  wanted in the first place (or made use of). Locks randomly changing
  their rank sounds like a disaster waiting to happen.
- In some places, we might be able to statically check that locks are
  taken in the right order (with the right lock rank checking
  implementation) as rank information is fully statically known.

This refactoring even more exposes the fact that Mutex has no lock rank
capabilites, which is not fixed here.

1 files changed, 2 insertions, 2 deletions

diff --git a/Kernel/Coredump.cpp b/Kernel/Coredump.cpp
index 3ffd60b133..ea36e60270 100644
--- a/Kernel/Coredump.cpp
+++ b/Kernel/Coredump.cpp
@@ -23,11 +23,11 @@
 
 #define INCLUDE_USERSPACE_HEAP_MEMORY_IN_COREDUMPS 0
 
-static Singleton<SpinlockProtected<OwnPtr<KString>>> s_coredump_directory_path;
+static Singleton<SpinlockProtected<OwnPtr<KString>, LockRank::None>> s_coredump_directory_path;
 
 namespace Kernel {
 
-SpinlockProtected<OwnPtr<KString>>& Coredump::directory_path()
+SpinlockProtected<OwnPtr<KString>, LockRank::None>& Coredump::directory_path()
 {
     return s_coredump_directory_path;
 }