Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Kernel/FileSystem/Custody.h

56 lines
1.6 KiB
C
Raw Normal View History

FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
#pragma once
FileSystem: Reuse existing custodies when possible, and keep them updated. Walk the custody cache and try to reuse an existing one when possible. The VFS is responsible for updating them when something happens that would cause the described relationship to change. This is definitely not perfect but it does work for the basic scenarios like renaming and removing directory entries.
2019-05-31 15:22:52 +02:00
#include <AK/Badge.h>
Kernel: Turns global Custody and Inode tables into InlineLinkedLists Yet more of this same thing. Each one of these patches has a small but noticeable impact on the steady-state kmalloc numbers. :^)
2019-08-08 11:08:27 +02:00
#include <AK/InlineLinkedList.h>
AK: Rename Retainable.h => RefCounted.h.
2019-06-21 18:58:45 +02:00
#include <AK/RefCounted.h>
Kernel: Turns global Custody and Inode tables into InlineLinkedLists Yet more of this same thing. Each one of these patches has a small but noticeable impact on the steady-state kmalloc numbers. :^)
2019-08-08 11:08:27 +02:00
#include <AK/RefPtr.h>
Kernel+LibC: Add support for mount flags At the moment, the actual flags are ignored, but we correctly propagate them all the way from the original mount() syscall to each custody that resides on the mounted FS.
2020-01-11 18:25:26 +03:00
#include <AK/String.h>
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
class Inode;
FileSystem: Reuse existing custodies when possible, and keep them updated. Walk the custody cache and try to reuse an existing one when possible. The VFS is responsible for updating them when something happens that would cause the described relationship to change. This is definitely not perfect but it does work for the basic scenarios like renaming and removing directory entries.
2019-05-31 15:22:52 +02:00
class VFS;
// FIXME: Custody needs some locking.
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
Kernel: Turns global Custody and Inode tables into InlineLinkedLists Yet more of this same thing. Each one of these patches has a small but noticeable impact on the steady-state kmalloc numbers. :^)
2019-08-08 11:08:27 +02:00
class Custody : public RefCounted<Custody>
, public InlineLinkedListNode<Custody> {
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
public:
Kernel: Don't create a String every time we look up a Custody by name
2019-08-24 22:01:17 +02:00
static Custody* get_if_cached(Custody* parent, const StringView& name);
Kernel+LibC: Add support for mount flags At the moment, the actual flags are ignored, but we correctly propagate them all the way from the original mount() syscall to each custody that resides on the mounted FS.
2020-01-11 18:25:26 +03:00
static NonnullRefPtr<Custody> get_or_create(Custody* parent, const StringView& name, Inode&, int mount_flags);
static NonnullRefPtr<Custody> create(Custody* parent, const StringView& name, Inode& inode, int mount_flags)
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
{
Kernel+LibC: Add support for mount flags At the moment, the actual flags are ignored, but we correctly propagate them all the way from the original mount() syscall to each custody that resides on the mounted FS.
2020-01-11 18:25:26 +03:00
return adopt(*new Custody(parent, name, inode, mount_flags));
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
}
~Custody();
Custody* parent() { return m_parent.ptr(); }
const Custody* parent() const { return m_parent.ptr(); }
Inode& inode() { return *m_inode; }
const Inode& inode() const { return *m_inode; }
const String& name() const { return m_name; }
FileSystem: Port most of the code over to using custodies. The current working directory is now stored as a custody. Likewise for a process executable file. This unbreaks /proc/PID/fd which has not been working since we made the filesystem bigger. This still needs a bunch of work, for instance when renaming or removing a file somewhere, we have to update the relevant custody links.
2019-05-30 18:58:59 +02:00
String absolute_path() const;
FileSystem: Reuse existing custodies when possible, and keep them updated. Walk the custody cache and try to reuse an existing one when possible. The VFS is responsible for updating them when something happens that would cause the described relationship to change. This is definitely not perfect but it does work for the basic scenarios like renaming and removing directory entries.
2019-05-31 15:22:52 +02:00
bool is_deleted() const { return m_deleted; }
bool is_mounted_on() const { return m_mounted_on; }
Kernel+LibC: Add support for mount flags At the moment, the actual flags are ignored, but we correctly propagate them all the way from the original mount() syscall to each custody that resides on the mounted FS.
2020-01-11 18:25:26 +03:00
int mount_flags() const { return m_mount_flags; }
FileSystem: Reuse existing custodies when possible, and keep them updated. Walk the custody cache and try to reuse an existing one when possible. The VFS is responsible for updating them when something happens that would cause the described relationship to change. This is definitely not perfect but it does work for the basic scenarios like renaming and removing directory entries.
2019-05-31 15:22:52 +02:00
void did_delete(Badge<VFS>);
void did_mount_on(Badge<VFS>);
void did_rename(Badge<VFS>, const String& name);
Kernel: Turns global Custody and Inode tables into InlineLinkedLists Yet more of this same thing. Each one of these patches has a small but noticeable impact on the steady-state kmalloc numbers. :^)
2019-08-08 11:08:27 +02:00
// For InlineLinkedListNode.
Custody* m_next { nullptr };
Custody* m_prev { nullptr };
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
private:
Kernel+LibC: Add support for mount flags At the moment, the actual flags are ignored, but we correctly propagate them all the way from the original mount() syscall to each custody that resides on the mounted FS.
2020-01-11 18:25:26 +03:00
Custody(Custody* parent, const StringView& name, Inode&, int mount_flags);
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
AK: Rename RetainPtr => RefPtr and Retained => NonnullRefPtr.
2019-06-21 18:37:47 +02:00
RefPtr<Custody> m_parent;
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
String m_name;
AK: Rename RetainPtr => RefPtr and Retained => NonnullRefPtr.
2019-06-21 18:37:47 +02:00
NonnullRefPtr<Inode> m_inode;
FileSystem: Reuse existing custodies when possible, and keep them updated. Walk the custody cache and try to reuse an existing one when possible. The VFS is responsible for updating them when something happens that would cause the described relationship to change. This is definitely not perfect but it does work for the basic scenarios like renaming and removing directory entries.
2019-05-31 15:22:52 +02:00
bool m_deleted { false };
bool m_mounted_on { false };
Kernel+LibC: Add support for mount flags At the moment, the actual flags are ignored, but we correctly propagate them all the way from the original mount() syscall to each custody that resides on the mounted FS.
2020-01-11 18:25:26 +03:00
int m_mount_flags { 0 };
FileSystem: Add a Custody class that represents a parent/child guardianship. A custody is kind of a directory entry abstraction that represents a single entry in a parent directory that tells us the name of a child inode. The idea here is for path resolution to produce a chain of custody objects.
2019-05-30 17:46:08 +02:00
};
Reference in a new issue Copy permalink