summaryrefslogtreecommitdiff
path: root/Kernel/FileSystem/Mount.cpp
AgeCommit message (Collapse)Author
2023-04-04Kernel: Simplify Mount internalsAndreas Kling
- The host custody never changes after initialization, so there's no need to protect it with a spinlock. - To enforce the fact that some members don't change after initialization, make them const.
2023-04-04Kernel: Stop using *LockRefPtr for FileSystem pointersAndreas Kling
There was only one permanent storage location for these: as a member in the Mount class. That member is never modified after Mount initialization, so we don't need to worry about races there.
2023-03-09Kernel: Switch LockRefPtr<Inode> to RefPtr<Inode>Andreas Kling
The main place where this is a little iffy is in RAMFS where inodes have a LockWeakPtr to their parent inode. I've left that as a LockWeakPtr for now.
2023-01-02Kernel: Turn lock ranks into template parameterskleines Filmröllchen
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.
2022-08-21Kernel: Use RefPtr instead of LockRefPtr for CustodyAndreas Kling
By protecting all the RefPtr<Custody> objects that may be accessed from multiple threads at the same time (with spinlocks), we remove the need for using LockRefPtr<Custody> (which is basically a RefPtr with a built-in spinlock.)
2022-01-12Kernel: Convert Mount::absolute_path to ErrorOr<NonnullOwnPtr<KString>>Idan Horowitz
2021-07-11Kernel: Make VirtualFileSystem::Mount a top-level classAndreas Kling
And move it to its own compilation unit.