2020-01-18 05:38:21 -03:00
|
|
|
/*
|
2020-01-24 10:45:29 -03:00
|
|
|
* Copyright (c) 2019-2020, Sergey Bugaev <bugaevc@serenityos.org>
|
Kernel/FileSystem: Send proper filetypes when traversing RAM-backed FSes
SysFS, ProcFS and DevPtsFS were all sending filetype 0 when traversing
their directories, but it is actually very easy to send proper filetypes
in these filesystems.
This patch binds all RAM backed filesystems to use only one enum for
their internal filetype, to simplify the implementation and allow
sharing of code.
Please note that the Plan9FS case is currently not solved as I am not
familiar with this filesystem and its constructs.
The ProcFS mostly keeps track of the filetype, and a fix was needed for
the /proc root directory - all processes exhibit a directory inside it
which makes it very easy to hardcode the directory filetype for them.
There's also the `self` symlink inode which is now exposed as DT_LNK.
As for SysFS, we could leverage the fact everything inherits from the
SysFSComponent class, so we could have a virtual const method to return
the proper filetype.
Most of the files in SysFS are "regular" files though, so the base class
has a non-pure virtual method.
Lastly, the DevPtsFS simply hardcodes '.' and '..' as directory file
type, and everything else is hardcoded to send the character device file
type, as this filesystem is only exposing character pts device files.
2024-01-05 06:18:02 -03:00
|
|
|
* Copyright (c) 2022-2024, Liav A. <liavalb@hotmail.co.il>
|
2020-01-18 05:38:21 -03:00
|
|
|
*
|
2021-04-22 05:24:48 -03:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-01-18 05:38:21 -03:00
|
|
|
*/
|
|
|
|
|
|
Kernel/FileSystem: Send proper filetypes when traversing RAM-backed FSes
SysFS, ProcFS and DevPtsFS were all sending filetype 0 when traversing
their directories, but it is actually very easy to send proper filetypes
in these filesystems.
This patch binds all RAM backed filesystems to use only one enum for
their internal filetype, to simplify the implementation and allow
sharing of code.
Please note that the Plan9FS case is currently not solved as I am not
familiar with this filesystem and its constructs.
The ProcFS mostly keeps track of the filetype, and a fix was needed for
the /proc root directory - all processes exhibit a directory inside it
which makes it very easy to hardcode the directory filetype for them.
There's also the `self` symlink inode which is now exposed as DT_LNK.
As for SysFS, we could leverage the fact everything inherits from the
SysFSComponent class, so we could have a virtual const method to return
the proper filetype.
Most of the files in SysFS are "regular" files though, so the base class
has a non-pure virtual method.
Lastly, the DevPtsFS simply hardcodes '.' and '..' as directory file
type, and everything else is hardcoded to send the character device file
type, as this filesystem is only exposing character pts device files.
2024-01-05 06:18:02 -03:00
|
|
|
#include <Kernel/FileSystem/RAMBackedFileType.h>
|
2023-12-01 14:37:25 -03:00
|
|
|
#include <Kernel/FileSystem/RAMFS/FileSystem.h>
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
#include <Kernel/FileSystem/RAMFS/Inode.h>
|
2023-02-24 14:45:37 -03:00
|
|
|
#include <Kernel/Tasks/Process.h>
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2020-02-15 21:27:42 -03:00
|
|
|
namespace Kernel {
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
RAMFSInode::RAMFSInode(RAMFS& fs, InodeMetadata const& metadata, LockWeakPtr<RAMFSInode> parent)
|
2019-08-15 12:16:45 -03:00
|
|
|
: Inode(fs, fs.next_inode_index())
|
|
|
|
|
, m_metadata(metadata)
|
2022-01-14 08:05:39 -03:00
|
|
|
, m_parent(move(parent))
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
|
|
|
|
m_metadata.inode = identifier();
|
|
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
RAMFSInode::RAMFSInode(RAMFS& fs)
|
2022-12-04 05:27:19 -03:00
|
|
|
: Inode(fs, 1)
|
|
|
|
|
, m_root_directory_inode(true)
|
|
|
|
|
{
|
|
|
|
|
auto now = kgettimeofday();
|
|
|
|
|
m_metadata.inode = identifier();
|
|
|
|
|
m_metadata.atime = now;
|
|
|
|
|
m_metadata.ctime = now;
|
|
|
|
|
m_metadata.mtime = now;
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
m_metadata.mode = S_IFDIR | 0755;
|
2022-12-04 05:27:19 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
RAMFSInode::~RAMFSInode() = default;
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2023-03-07 08:25:00 -03:00
|
|
|
ErrorOr<NonnullRefPtr<RAMFSInode>> RAMFSInode::try_create(RAMFS& fs, InodeMetadata const& metadata, LockWeakPtr<RAMFSInode> parent)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2023-03-07 08:25:00 -03:00
|
|
|
return adopt_nonnull_ref_or_enomem(new (nothrow) RAMFSInode(fs, metadata, move(parent)));
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
2023-03-07 08:25:00 -03:00
|
|
|
ErrorOr<NonnullRefPtr<RAMFSInode>> RAMFSInode::try_create_root(RAMFS& fs)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2023-03-07 08:25:00 -03:00
|
|
|
return adopt_nonnull_ref_or_enomem(new (nothrow) RAMFSInode(fs));
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
InodeMetadata RAMFSInode::metadata() const
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock, Mutex::Mode::Shared);
|
2019-08-15 12:16:45 -03:00
|
|
|
|
|
|
|
|
return m_metadata;
|
|
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::traverse_as_directory(Function<ErrorOr<void>(FileSystem::DirectoryEntryView const&)> callback) const
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock, Mutex::Mode::Shared);
|
2019-08-15 12:16:45 -03:00
|
|
|
|
|
|
|
|
if (!is_directory())
|
2021-01-20 19:11:17 -03:00
|
|
|
return ENOTDIR;
|
2019-08-15 12:16:45 -03:00
|
|
|
|
Kernel/FileSystem: Send proper filetypes when traversing RAM-backed FSes
SysFS, ProcFS and DevPtsFS were all sending filetype 0 when traversing
their directories, but it is actually very easy to send proper filetypes
in these filesystems.
This patch binds all RAM backed filesystems to use only one enum for
their internal filetype, to simplify the implementation and allow
sharing of code.
Please note that the Plan9FS case is currently not solved as I am not
familiar with this filesystem and its constructs.
The ProcFS mostly keeps track of the filetype, and a fix was needed for
the /proc root directory - all processes exhibit a directory inside it
which makes it very easy to hardcode the directory filetype for them.
There's also the `self` symlink inode which is now exposed as DT_LNK.
As for SysFS, we could leverage the fact everything inherits from the
SysFSComponent class, so we could have a virtual const method to return
the proper filetype.
Most of the files in SysFS are "regular" files though, so the base class
has a non-pure virtual method.
Lastly, the DevPtsFS simply hardcodes '.' and '..' as directory file
type, and everything else is hardcoded to send the character device file
type, as this filesystem is only exposing character pts device files.
2024-01-05 06:18:02 -03:00
|
|
|
TRY(callback({ "."sv, identifier(), to_underlying(RAMBackedFileType::Directory) }));
|
2022-12-04 05:27:19 -03:00
|
|
|
if (m_root_directory_inode) {
|
Kernel/FileSystem: Send proper filetypes when traversing RAM-backed FSes
SysFS, ProcFS and DevPtsFS were all sending filetype 0 when traversing
their directories, but it is actually very easy to send proper filetypes
in these filesystems.
This patch binds all RAM backed filesystems to use only one enum for
their internal filetype, to simplify the implementation and allow
sharing of code.
Please note that the Plan9FS case is currently not solved as I am not
familiar with this filesystem and its constructs.
The ProcFS mostly keeps track of the filetype, and a fix was needed for
the /proc root directory - all processes exhibit a directory inside it
which makes it very easy to hardcode the directory filetype for them.
There's also the `self` symlink inode which is now exposed as DT_LNK.
As for SysFS, we could leverage the fact everything inherits from the
SysFSComponent class, so we could have a virtual const method to return
the proper filetype.
Most of the files in SysFS are "regular" files though, so the base class
has a non-pure virtual method.
Lastly, the DevPtsFS simply hardcodes '.' and '..' as directory file
type, and everything else is hardcoded to send the character device file
type, as this filesystem is only exposing character pts device files.
2024-01-05 06:18:02 -03:00
|
|
|
TRY(callback({ ".."sv, identifier(), to_underlying(RAMBackedFileType::Directory) }));
|
2022-12-04 05:27:19 -03:00
|
|
|
} else if (auto parent = m_parent.strong_ref()) {
|
Kernel/FileSystem: Send proper filetypes when traversing RAM-backed FSes
SysFS, ProcFS and DevPtsFS were all sending filetype 0 when traversing
their directories, but it is actually very easy to send proper filetypes
in these filesystems.
This patch binds all RAM backed filesystems to use only one enum for
their internal filetype, to simplify the implementation and allow
sharing of code.
Please note that the Plan9FS case is currently not solved as I am not
familiar with this filesystem and its constructs.
The ProcFS mostly keeps track of the filetype, and a fix was needed for
the /proc root directory - all processes exhibit a directory inside it
which makes it very easy to hardcode the directory filetype for them.
There's also the `self` symlink inode which is now exposed as DT_LNK.
As for SysFS, we could leverage the fact everything inherits from the
SysFSComponent class, so we could have a virtual const method to return
the proper filetype.
Most of the files in SysFS are "regular" files though, so the base class
has a non-pure virtual method.
Lastly, the DevPtsFS simply hardcodes '.' and '..' as directory file
type, and everything else is hardcoded to send the character device file
type, as this filesystem is only exposing character pts device files.
2024-01-05 06:18:02 -03:00
|
|
|
TRY(callback({ ".."sv, parent->identifier(), to_underlying(RAMBackedFileType::Directory) }));
|
2022-12-04 05:27:19 -03:00
|
|
|
}
|
2020-01-10 08:35:18 -03:00
|
|
|
|
2021-07-18 08:47:18 -03:00
|
|
|
for (auto& child : m_children) {
|
Kernel/FileSystem: Send proper filetypes when traversing RAM-backed FSes
SysFS, ProcFS and DevPtsFS were all sending filetype 0 when traversing
their directories, but it is actually very easy to send proper filetypes
in these filesystems.
This patch binds all RAM backed filesystems to use only one enum for
their internal filetype, to simplify the implementation and allow
sharing of code.
Please note that the Plan9FS case is currently not solved as I am not
familiar with this filesystem and its constructs.
The ProcFS mostly keeps track of the filetype, and a fix was needed for
the /proc root directory - all processes exhibit a directory inside it
which makes it very easy to hardcode the directory filetype for them.
There's also the `self` symlink inode which is now exposed as DT_LNK.
As for SysFS, we could leverage the fact everything inherits from the
SysFSComponent class, so we could have a virtual const method to return
the proper filetype.
Most of the files in SysFS are "regular" files though, so the base class
has a non-pure virtual method.
Lastly, the DevPtsFS simply hardcodes '.' and '..' as directory file
type, and everything else is hardcoded to send the character device file
type, as this filesystem is only exposing character pts device files.
2024-01-05 06:18:02 -03:00
|
|
|
TRY(callback({ child.name->view(), child.inode->identifier(), to_underlying(ram_backed_file_type_from_mode(child.inode->metadata().mode)) }));
|
2020-08-18 07:41:27 -03:00
|
|
|
}
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::replace_child(StringView name, Inode& new_child)
|
2022-10-08 06:22:12 -03:00
|
|
|
{
|
|
|
|
|
MutexLocker locker(m_inode_lock);
|
|
|
|
|
VERIFY(is_directory());
|
|
|
|
|
VERIFY(new_child.fsid() == fsid());
|
|
|
|
|
|
|
|
|
|
auto* child = find_child_by_name(name);
|
|
|
|
|
if (!child)
|
|
|
|
|
return ENOENT;
|
|
|
|
|
|
|
|
|
|
auto old_child = child->inode;
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
child->inode = static_cast<RAMFSInode&>(new_child);
|
2022-10-08 06:22:12 -03:00
|
|
|
|
|
|
|
|
old_child->did_delete_self();
|
|
|
|
|
|
|
|
|
|
// TODO: Emit a did_replace_child event.
|
|
|
|
|
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<NonnullOwnPtr<RAMFSInode::DataBlock>> RAMFSInode::DataBlock::create()
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2022-09-09 00:58:44 -03:00
|
|
|
auto data_block_buffer_vmobject = TRY(Memory::AnonymousVMObject::try_create_with_size(DataBlock::block_size, AllocationStrategy::AllocateNow));
|
|
|
|
|
return TRY(adopt_nonnull_own_or_enomem(new (nothrow) DataBlock(move(data_block_buffer_vmobject))));
|
|
|
|
|
}
|
2019-08-15 12:16:45 -03:00
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::ensure_allocated_blocks(size_t offset, size_t io_size)
|
2022-09-09 00:58:44 -03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
|
|
|
|
size_t block_start_index = offset / DataBlock::block_size;
|
|
|
|
|
size_t block_last_index = ((offset + io_size) / DataBlock::block_size) + (((offset + io_size) % DataBlock::block_size) == 0 ? 0 : 1);
|
|
|
|
|
VERIFY(block_start_index <= block_last_index);
|
|
|
|
|
|
|
|
|
|
size_t original_size = m_blocks.size();
|
|
|
|
|
Vector<size_t> allocated_block_indices;
|
|
|
|
|
ArmedScopeGuard clean_allocated_blocks_on_failure([&] {
|
|
|
|
|
for (auto index : allocated_block_indices)
|
|
|
|
|
m_blocks[index].clear();
|
|
|
|
|
MUST(m_blocks.try_resize(original_size));
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
if (m_blocks.size() < (block_last_index))
|
|
|
|
|
TRY(m_blocks.try_resize(block_last_index));
|
|
|
|
|
|
|
|
|
|
for (size_t block_index = block_start_index; block_index < block_last_index; block_index++) {
|
|
|
|
|
if (!m_blocks[block_index]) {
|
|
|
|
|
TRY(allocated_block_indices.try_append(block_index));
|
|
|
|
|
m_blocks[block_index] = TRY(DataBlock::create());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
clean_allocated_blocks_on_failure.disarm();
|
|
|
|
|
return {};
|
|
|
|
|
}
|
2019-08-15 12:16:45 -03:00
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<size_t> RAMFSInode::read_bytes_from_content_space(size_t offset, size_t io_size, UserOrKernelBuffer& buffer) const
|
2022-09-09 00:58:44 -03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
|
|
|
|
VERIFY(m_metadata.size >= 0);
|
2023-02-18 11:48:45 -03:00
|
|
|
if (offset >= static_cast<size_t>(m_metadata.size))
|
2020-01-08 08:45:39 -03:00
|
|
|
return 0;
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
auto mapping_region = TRY(MM.allocate_kernel_region(DataBlock::block_size, "RAMFSInode Mapping Region"sv, Memory::Region::Access::Read, AllocationStrategy::Reserve));
|
|
|
|
|
return const_cast<RAMFSInode&>(*this).do_io_on_content_space(*mapping_region, offset, io_size, buffer, false);
|
2022-09-09 00:58:44 -03:00
|
|
|
}
|
2020-01-08 08:45:39 -03:00
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<size_t> RAMFSInode::read_bytes_locked(off_t offset, size_t size, UserOrKernelBuffer& buffer, OpenFileDescription*) const
|
2022-09-09 00:58:44 -03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
|
|
|
|
VERIFY(!is_directory());
|
|
|
|
|
return read_bytes_from_content_space(offset, size, buffer);
|
|
|
|
|
}
|
2019-08-15 12:16:45 -03:00
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<size_t> RAMFSInode::write_bytes_to_content_space(size_t offset, size_t io_size, UserOrKernelBuffer const& buffer)
|
2022-09-09 00:58:44 -03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
auto mapping_region = TRY(MM.allocate_kernel_region(DataBlock::block_size, "RAMFSInode Mapping Region"sv, Memory::Region::Access::Write, AllocationStrategy::Reserve));
|
2022-09-09 00:58:44 -03:00
|
|
|
return do_io_on_content_space(*mapping_region, offset, io_size, const_cast<UserOrKernelBuffer&>(buffer), true);
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<size_t> RAMFSInode::write_bytes_locked(off_t offset, size_t size, UserOrKernelBuffer const& buffer, OpenFileDescription*)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2022-07-27 15:42:16 -03:00
|
|
|
VERIFY(m_inode_lock.is_locked());
|
2021-02-23 16:42:32 -03:00
|
|
|
VERIFY(!is_directory());
|
|
|
|
|
VERIFY(offset >= 0);
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2022-09-09 00:58:44 -03:00
|
|
|
TRY(ensure_allocated_blocks(offset, size));
|
|
|
|
|
auto nwritten = TRY(write_bytes_to_content_space(offset, size, buffer));
|
|
|
|
|
|
2019-08-24 14:52:18 -03:00
|
|
|
off_t old_size = m_metadata.size;
|
|
|
|
|
off_t new_size = m_metadata.size;
|
2021-07-07 03:17:22 -03:00
|
|
|
if (static_cast<off_t>(offset + size) > new_size)
|
2019-08-24 14:52:18 -03:00
|
|
|
new_size = offset + size;
|
|
|
|
|
|
|
|
|
|
if (new_size > old_size) {
|
|
|
|
|
m_metadata.size = new_size;
|
2021-12-28 08:33:27 -03:00
|
|
|
set_metadata_dirty(true);
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
2022-09-09 00:58:44 -03:00
|
|
|
did_modify_contents();
|
|
|
|
|
return nwritten;
|
|
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<size_t> RAMFSInode::do_io_on_content_space(Memory::Region& mapping_region, size_t offset, size_t io_size, UserOrKernelBuffer& buffer, bool write)
|
2022-09-09 00:58:44 -03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
|
|
|
|
size_t remaining_bytes = 0;
|
|
|
|
|
if (!write) {
|
|
|
|
|
// Note: For read operations, only perform read until the last byte.
|
|
|
|
|
// If we are beyond the last byte, return 0 to indicate EOF.
|
|
|
|
|
remaining_bytes = min(io_size, m_metadata.size - offset);
|
|
|
|
|
if (remaining_bytes == 0)
|
|
|
|
|
return 0;
|
|
|
|
|
} else {
|
|
|
|
|
remaining_bytes = io_size;
|
|
|
|
|
}
|
|
|
|
|
VERIFY(remaining_bytes != 0);
|
|
|
|
|
|
|
|
|
|
UserOrKernelBuffer current_buffer = buffer.offset(0);
|
|
|
|
|
auto block_start_index = offset / DataBlock::block_size;
|
|
|
|
|
auto offset_in_block = offset % DataBlock::block_size;
|
|
|
|
|
u64 block_index = block_start_index;
|
|
|
|
|
size_t nio = 0;
|
|
|
|
|
while (remaining_bytes > 0) {
|
|
|
|
|
size_t current_io_size = min(DataBlock::block_size - offset_in_block, remaining_bytes);
|
|
|
|
|
auto& block = m_blocks[block_index];
|
|
|
|
|
if (!block && !write) {
|
|
|
|
|
// Note: If the block does not exist then it's just a gap in the file,
|
|
|
|
|
// so the buffer should be placed with zeroes in that section.
|
|
|
|
|
TRY(current_buffer.memset(0, 0, current_io_size));
|
|
|
|
|
remaining_bytes -= current_io_size;
|
|
|
|
|
current_buffer = current_buffer.offset(current_io_size);
|
|
|
|
|
nio += current_io_size;
|
|
|
|
|
block_index++;
|
|
|
|
|
// Note: Clear offset_in_block to zero to ensure that if we started from a middle of
|
|
|
|
|
// a block, then next writes are just going to happen from the start of each block until the end.
|
|
|
|
|
offset_in_block = 0;
|
|
|
|
|
continue;
|
|
|
|
|
} else if (!block) {
|
|
|
|
|
return Error::from_errno(EIO);
|
|
|
|
|
}
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2022-09-09 00:58:44 -03:00
|
|
|
NonnullLockRefPtr<Memory::AnonymousVMObject> block_vmobject = block->vmobject();
|
|
|
|
|
mapping_region.set_vmobject(block_vmobject);
|
|
|
|
|
mapping_region.remap();
|
|
|
|
|
if (write)
|
|
|
|
|
TRY(current_buffer.read(mapping_region.vaddr().offset(offset_in_block).as_ptr(), 0, current_io_size));
|
|
|
|
|
else
|
|
|
|
|
TRY(current_buffer.write(mapping_region.vaddr().offset(offset_in_block).as_ptr(), 0, current_io_size));
|
|
|
|
|
current_buffer = current_buffer.offset(current_io_size);
|
|
|
|
|
nio += current_io_size;
|
|
|
|
|
remaining_bytes -= current_io_size;
|
|
|
|
|
block_index++;
|
|
|
|
|
// Note: Clear offset_in_block to zero to ensure that if we started from a middle of
|
|
|
|
|
// a block, then next writes are just going to happen from the start of each block until the end.
|
|
|
|
|
offset_in_block = 0;
|
|
|
|
|
}
|
|
|
|
|
VERIFY(nio <= io_size);
|
|
|
|
|
return nio;
|
|
|
|
|
}
|
2021-05-12 16:17:51 -03:00
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::truncate_to_block_index(size_t block_index)
|
2022-09-09 00:58:44 -03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
|
|
|
|
TRY(m_blocks.try_resize(block_index));
|
|
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
2023-03-07 08:25:00 -03:00
|
|
|
ErrorOr<NonnullRefPtr<Inode>> RAMFSInode::lookup(StringView name)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock, Mutex::Mode::Shared);
|
2021-02-23 16:42:32 -03:00
|
|
|
VERIFY(is_directory());
|
2019-08-15 12:16:45 -03:00
|
|
|
|
|
|
|
|
if (name == ".")
|
2021-08-14 08:32:35 -03:00
|
|
|
return *this;
|
2022-01-14 08:05:39 -03:00
|
|
|
if (name == "..") {
|
|
|
|
|
if (auto parent = m_parent.strong_ref())
|
2023-03-07 08:25:00 -03:00
|
|
|
return *parent;
|
2022-01-14 08:05:39 -03:00
|
|
|
return ENOENT;
|
|
|
|
|
}
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2021-07-18 08:47:18 -03:00
|
|
|
auto* child = find_child_by_name(name);
|
|
|
|
|
if (!child)
|
2021-08-14 08:32:35 -03:00
|
|
|
return ENOENT;
|
2021-07-18 08:47:18 -03:00
|
|
|
return child->inode;
|
|
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
RAMFSInode::Child* RAMFSInode::find_child_by_name(StringView name)
|
2021-07-18 08:47:18 -03:00
|
|
|
{
|
|
|
|
|
for (auto& child : m_children) {
|
|
|
|
|
if (child.name->view() == name)
|
|
|
|
|
return &child;
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::flush_metadata()
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
|
|
|
|
// We don't really have any metadata that could become dirty.
|
|
|
|
|
// The only reason we even call set_metadata_dirty() is
|
|
|
|
|
// to let the watchers know we have updates. Once that is
|
|
|
|
|
// switched to a different mechanism, we can stop ever marking
|
|
|
|
|
// our metadata as dirty at all.
|
|
|
|
|
set_metadata_dirty(false);
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::chmod(mode_t mode)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2019-08-15 12:16:45 -03:00
|
|
|
|
|
|
|
|
m_metadata.mode = mode;
|
2021-12-28 08:33:27 -03:00
|
|
|
set_metadata_dirty(true);
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::chown(UserID uid, GroupID gid)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2019-08-15 12:16:45 -03:00
|
|
|
|
|
|
|
|
m_metadata.uid = uid;
|
|
|
|
|
m_metadata.gid = gid;
|
2021-12-28 08:33:27 -03:00
|
|
|
set_metadata_dirty(true);
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
2023-03-07 08:25:00 -03:00
|
|
|
ErrorOr<NonnullRefPtr<Inode>> RAMFSInode::create_child(StringView name, mode_t mode, dev_t dev, UserID uid, GroupID gid)
|
2020-06-24 17:35:56 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2022-11-22 17:01:45 -03:00
|
|
|
auto now = kgettimeofday();
|
2020-06-24 17:35:56 -03:00
|
|
|
|
|
|
|
|
InodeMetadata metadata;
|
|
|
|
|
metadata.mode = mode;
|
|
|
|
|
metadata.uid = uid;
|
|
|
|
|
metadata.gid = gid;
|
2021-02-27 22:18:48 -03:00
|
|
|
metadata.atime = now;
|
|
|
|
|
metadata.ctime = now;
|
|
|
|
|
metadata.mtime = now;
|
2022-10-21 12:39:41 -03:00
|
|
|
metadata.major_device = major_from_encoded_device(dev);
|
|
|
|
|
metadata.minor_device = minor_from_encoded_device(dev);
|
2020-06-24 17:35:56 -03:00
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
auto child = TRY(RAMFSInode::try_create(fs(), metadata, *this));
|
2021-09-05 21:28:38 -03:00
|
|
|
TRY(add_child(*child, name, mode));
|
|
|
|
|
return child;
|
2020-06-24 17:35:56 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::add_child(Inode& child, StringView name, mode_t)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-02-23 16:42:32 -03:00
|
|
|
VERIFY(is_directory());
|
|
|
|
|
VERIFY(child.fsid() == fsid());
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2020-10-22 13:59:00 -03:00
|
|
|
if (name.length() > NAME_MAX)
|
2021-01-20 19:11:17 -03:00
|
|
|
return ENAMETOOLONG;
|
2020-10-22 13:59:00 -03:00
|
|
|
|
2022-01-01 18:18:59 -03:00
|
|
|
MutexLocker locker(m_inode_lock);
|
|
|
|
|
for (auto const& existing_child : m_children) {
|
|
|
|
|
if (existing_child.name->view() == name)
|
|
|
|
|
return EEXIST;
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-06 14:24:54 -03:00
|
|
|
auto name_kstring = TRY(KString::try_create(name));
|
2021-09-07 15:10:06 -03:00
|
|
|
// Balanced by `delete` in remove_child()
|
2022-01-01 18:18:59 -03:00
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
auto* child_entry = new (nothrow) Child { move(name_kstring), static_cast<RAMFSInode&>(child) };
|
2021-07-18 08:47:18 -03:00
|
|
|
if (!child_entry)
|
|
|
|
|
return ENOMEM;
|
|
|
|
|
|
|
|
|
|
m_children.append(*child_entry);
|
2021-05-12 16:17:51 -03:00
|
|
|
did_add_child(child.identifier(), name);
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::remove_child(StringView name)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2021-02-23 16:42:32 -03:00
|
|
|
VERIFY(is_directory());
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2020-01-10 08:35:18 -03:00
|
|
|
if (name == "." || name == "..")
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2020-01-10 08:35:18 -03:00
|
|
|
|
2021-07-18 08:47:18 -03:00
|
|
|
auto* child = find_child_by_name(name);
|
|
|
|
|
if (!child)
|
2021-01-20 19:11:17 -03:00
|
|
|
return ENOENT;
|
2021-07-18 08:47:18 -03:00
|
|
|
|
|
|
|
|
auto child_id = child->inode->identifier();
|
|
|
|
|
child->inode->did_delete_self();
|
|
|
|
|
m_children.remove(*child);
|
2021-05-12 16:17:51 -03:00
|
|
|
did_remove_child(child_id, name);
|
2021-09-07 15:10:06 -03:00
|
|
|
// Balanced by `new` in add_child()
|
|
|
|
|
delete child;
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
ErrorOr<void> RAMFSInode::truncate(u64 size)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2021-02-23 16:42:32 -03:00
|
|
|
VERIFY(!is_directory());
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2022-09-09 00:58:44 -03:00
|
|
|
u64 block_index = size / DataBlock::block_size + ((size % DataBlock::block_size == 0) ? 0 : 1);
|
|
|
|
|
TRY(truncate_to_block_index(block_index));
|
|
|
|
|
|
|
|
|
|
u64 last_possible_block_index = size / DataBlock::block_size;
|
|
|
|
|
if ((size % DataBlock::block_size != 0) && m_blocks[last_possible_block_index]) {
|
Kernel+SystemServer+Base: Introduce the RAMFS filesystem
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
2023-01-28 14:00:54 -03:00
|
|
|
auto mapping_region = TRY(MM.allocate_kernel_region(DataBlock::block_size, "RAMFSInode Mapping Region"sv, Memory::Region::Access::Write, AllocationStrategy::Reserve));
|
2022-09-09 00:58:44 -03:00
|
|
|
VERIFY(m_blocks[last_possible_block_index]);
|
|
|
|
|
NonnullLockRefPtr<Memory::AnonymousVMObject> block_vmobject = m_blocks[last_possible_block_index]->vmobject();
|
|
|
|
|
mapping_region->set_vmobject(block_vmobject);
|
|
|
|
|
mapping_region->remap();
|
|
|
|
|
memset(mapping_region->vaddr().offset(size % DataBlock::block_size).as_ptr(), 0, DataBlock::block_size - (size % DataBlock::block_size));
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
m_metadata.size = size;
|
2021-12-28 08:33:27 -03:00
|
|
|
set_metadata_dirty(true);
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
2023-03-13 18:11:13 -03:00
|
|
|
ErrorOr<void> RAMFSInode::update_timestamps(Optional<UnixDateTime> atime, Optional<UnixDateTime> ctime, Optional<UnixDateTime> mtime)
|
2019-08-15 12:16:45 -03:00
|
|
|
{
|
2021-07-17 20:13:34 -03:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2019-08-15 12:16:45 -03:00
|
|
|
|
2022-08-22 08:34:22 -03:00
|
|
|
if (atime.has_value())
|
|
|
|
|
m_metadata.atime = atime.value();
|
|
|
|
|
if (ctime.has_value())
|
|
|
|
|
m_metadata.ctime = ctime.value();
|
|
|
|
|
if (mtime.has_value())
|
2022-11-22 17:02:32 -03:00
|
|
|
m_metadata.mtime = mtime.value();
|
2021-12-28 08:33:27 -03:00
|
|
|
set_metadata_dirty(true);
|
2021-11-07 20:51:39 -03:00
|
|
|
return {};
|
2019-08-15 12:16:45 -03:00
|
|
|
}
|
|
|
|
|
|
2020-02-15 21:27:42 -03:00
|
|
|
}
|