2020-01-18 09:38:21 +01:00
|
|
|
/*
|
2020-01-24 16:45:29 +03:00
|
|
|
* Copyright (c) 2019-2020, Sergey Bugaev <bugaevc@serenityos.org>
|
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 19:00:54 +02:00
|
|
|
* Copyright (c) 2022-2023, Liav A. <liavalb@hotmail.co.il>
|
2020-01-18 09:38:21 +01:00
|
|
|
*
|
2021-04-22 01:24:48 -07:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-01-18 09:38:21 +01: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 19:00:54 +02:00
|
|
|
#include <Kernel/FileSystem/RAMFS/Inode.h>
|
2023-02-24 19:45:37 +02:00
|
|
|
#include <Kernel/Tasks/Process.h>
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2020-02-16 01:27:42 +01: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 19:00:54 +02:00
|
|
|
RAMFSInode::RAMFSInode(RAMFS& fs, InodeMetadata const& metadata, LockWeakPtr<RAMFSInode> parent)
|
2019-08-15 18:16:45 +03:00
|
|
|
: Inode(fs, fs.next_inode_index())
|
|
|
|
|
, m_metadata(metadata)
|
2022-01-14 12:05:39 +01:00
|
|
|
, m_parent(move(parent))
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
RAMFSInode::RAMFSInode(RAMFS& fs)
|
2022-12-04 10:27:19 +02: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 19:00:54 +02:00
|
|
|
m_metadata.mode = S_IFDIR | 0755;
|
2022-12-04 10:27:19 +02: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 19:00:54 +02:00
|
|
|
RAMFSInode::~RAMFSInode() = default;
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2023-03-07 12:25:00 +01:00
|
|
|
ErrorOr<NonnullRefPtr<RAMFSInode>> RAMFSInode::try_create(RAMFS& fs, InodeMetadata const& metadata, LockWeakPtr<RAMFSInode> parent)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2023-03-07 12:25:00 +01:00
|
|
|
return adopt_nonnull_ref_or_enomem(new (nothrow) RAMFSInode(fs, metadata, move(parent)));
|
2019-08-15 18:16:45 +03:00
|
|
|
}
|
|
|
|
|
|
2023-03-07 12:25:00 +01:00
|
|
|
ErrorOr<NonnullRefPtr<RAMFSInode>> RAMFSInode::try_create_root(RAMFS& fs)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2023-03-07 12:25:00 +01:00
|
|
|
return adopt_nonnull_ref_or_enomem(new (nothrow) RAMFSInode(fs));
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
InodeMetadata RAMFSInode::metadata() const
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock, Mutex::Mode::Shared);
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::traverse_as_directory(Function<ErrorOr<void>(FileSystem::DirectoryEntryView const&)> callback) const
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock, Mutex::Mode::Shared);
|
2019-08-15 18:16:45 +03:00
|
|
|
|
|
|
|
|
if (!is_directory())
|
2021-01-20 23:11:17 +01:00
|
|
|
return ENOTDIR;
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2022-07-11 17:32:29 +00:00
|
|
|
TRY(callback({ "."sv, identifier(), 0 }));
|
2022-12-04 10:27:19 +02:00
|
|
|
if (m_root_directory_inode) {
|
|
|
|
|
TRY(callback({ ".."sv, identifier(), 0 }));
|
|
|
|
|
} else if (auto parent = m_parent.strong_ref()) {
|
2022-07-11 17:32:29 +00:00
|
|
|
TRY(callback({ ".."sv, parent->identifier(), 0 }));
|
2022-12-04 10:27:19 +02:00
|
|
|
}
|
2020-01-10 12:35:18 +01:00
|
|
|
|
2021-07-18 13:47:18 +02:00
|
|
|
for (auto& child : m_children) {
|
2021-11-10 15:42:39 +01:00
|
|
|
TRY(callback({ child.name->view(), child.inode->identifier(), 0 }));
|
2020-08-18 12:41:27 +02:00
|
|
|
}
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::replace_child(StringView name, Inode& new_child)
|
2022-10-08 11:22:12 +02: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 19:00:54 +02:00
|
|
|
child->inode = static_cast<RAMFSInode&>(new_child);
|
2022-10-08 11:22:12 +02: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 19:00:54 +02:00
|
|
|
ErrorOr<NonnullOwnPtr<RAMFSInode::DataBlock>> RAMFSInode::DataBlock::create()
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2022-09-09 06: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 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::ensure_allocated_blocks(size_t offset, size_t io_size)
|
2022-09-09 06: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 18: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 19:00:54 +02:00
|
|
|
ErrorOr<size_t> RAMFSInode::read_bytes_from_content_space(size_t offset, size_t io_size, UserOrKernelBuffer& buffer) const
|
2022-09-09 06:58:44 +03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
|
|
|
|
VERIFY(m_metadata.size >= 0);
|
2023-02-18 16:48:45 +02:00
|
|
|
if (offset >= static_cast<size_t>(m_metadata.size))
|
2020-01-08 12:45:39 +01: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 19:00:54 +02: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 06:58:44 +03:00
|
|
|
}
|
2020-01-08 12:45:39 +01: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 19:00:54 +02:00
|
|
|
ErrorOr<size_t> RAMFSInode::read_bytes_locked(off_t offset, size_t size, UserOrKernelBuffer& buffer, OpenFileDescription*) const
|
2022-09-09 06: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 18: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 19:00:54 +02:00
|
|
|
ErrorOr<size_t> RAMFSInode::write_bytes_to_content_space(size_t offset, size_t io_size, UserOrKernelBuffer const& buffer)
|
2022-09-09 06: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 19:00:54 +02: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 06:58:44 +03:00
|
|
|
return do_io_on_content_space(*mapping_region, offset, io_size, const_cast<UserOrKernelBuffer&>(buffer), true);
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<size_t> RAMFSInode::write_bytes_locked(off_t offset, size_t size, UserOrKernelBuffer const& buffer, OpenFileDescription*)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2022-07-27 21:42:16 +03:00
|
|
|
VERIFY(m_inode_lock.is_locked());
|
2021-02-23 20:42:32 +01:00
|
|
|
VERIFY(!is_directory());
|
|
|
|
|
VERIFY(offset >= 0);
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2022-09-09 06:58:44 +03:00
|
|
|
TRY(ensure_allocated_blocks(offset, size));
|
|
|
|
|
auto nwritten = TRY(write_bytes_to_content_space(offset, size, buffer));
|
|
|
|
|
|
2019-08-24 19:52:18 +02:00
|
|
|
off_t old_size = m_metadata.size;
|
|
|
|
|
off_t new_size = m_metadata.size;
|
2021-07-07 00:17:22 -06:00
|
|
|
if (static_cast<off_t>(offset + size) > new_size)
|
2019-08-24 19:52:18 +02:00
|
|
|
new_size = offset + size;
|
|
|
|
|
|
|
|
|
|
if (new_size > old_size) {
|
|
|
|
|
m_metadata.size = new_size;
|
2021-12-28 12:33:27 +01:00
|
|
|
set_metadata_dirty(true);
|
2019-08-15 18:16:45 +03:00
|
|
|
}
|
2022-09-09 06: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 19:00:54 +02: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 06: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 18:16:45 +03:00
|
|
|
|
2022-09-09 06: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 19:17:51 +00: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::truncate_to_block_index(size_t block_index)
|
2022-09-09 06:58:44 +03:00
|
|
|
{
|
|
|
|
|
VERIFY(m_inode_lock.is_locked());
|
|
|
|
|
TRY(m_blocks.try_resize(block_index));
|
|
|
|
|
return {};
|
2019-08-15 18:16:45 +03:00
|
|
|
}
|
|
|
|
|
|
2023-03-07 12:25:00 +01:00
|
|
|
ErrorOr<NonnullRefPtr<Inode>> RAMFSInode::lookup(StringView name)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock, Mutex::Mode::Shared);
|
2021-02-23 20:42:32 +01:00
|
|
|
VERIFY(is_directory());
|
2019-08-15 18:16:45 +03:00
|
|
|
|
|
|
|
|
if (name == ".")
|
2021-08-14 13:32:35 +02:00
|
|
|
return *this;
|
2022-01-14 12:05:39 +01:00
|
|
|
if (name == "..") {
|
|
|
|
|
if (auto parent = m_parent.strong_ref())
|
2023-03-07 12:25:00 +01:00
|
|
|
return *parent;
|
2022-01-14 12:05:39 +01:00
|
|
|
return ENOENT;
|
|
|
|
|
}
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2021-07-18 13:47:18 +02:00
|
|
|
auto* child = find_child_by_name(name);
|
|
|
|
|
if (!child)
|
2021-08-14 13:32:35 +02:00
|
|
|
return ENOENT;
|
2021-07-18 13:47:18 +02: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 19:00:54 +02:00
|
|
|
RAMFSInode::Child* RAMFSInode::find_child_by_name(StringView name)
|
2021-07-18 13:47:18 +02:00
|
|
|
{
|
|
|
|
|
for (auto& child : m_children) {
|
|
|
|
|
if (child.name->view() == name)
|
|
|
|
|
return &child;
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::flush_metadata()
|
2019-08-15 18: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-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::chmod(mode_t mode)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2019-08-15 18:16:45 +03:00
|
|
|
|
|
|
|
|
m_metadata.mode = mode;
|
2021-12-28 12:33:27 +01:00
|
|
|
set_metadata_dirty(true);
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::chown(UserID uid, GroupID gid)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2019-08-15 18:16:45 +03:00
|
|
|
|
|
|
|
|
m_metadata.uid = uid;
|
|
|
|
|
m_metadata.gid = gid;
|
2021-12-28 12:33:27 +01:00
|
|
|
set_metadata_dirty(true);
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18:16:45 +03:00
|
|
|
}
|
|
|
|
|
|
2023-03-07 12:25:00 +01:00
|
|
|
ErrorOr<NonnullRefPtr<Inode>> RAMFSInode::create_child(StringView name, mode_t mode, dev_t dev, UserID uid, GroupID gid)
|
2020-06-24 23:35:56 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2022-11-22 21:01:45 +01:00
|
|
|
auto now = kgettimeofday();
|
2020-06-24 23:35:56 +03:00
|
|
|
|
|
|
|
|
InodeMetadata metadata;
|
|
|
|
|
metadata.mode = mode;
|
|
|
|
|
metadata.uid = uid;
|
|
|
|
|
metadata.gid = gid;
|
2021-02-28 02:18:48 +01:00
|
|
|
metadata.atime = now;
|
|
|
|
|
metadata.ctime = now;
|
|
|
|
|
metadata.mtime = now;
|
2022-10-21 18:39:41 +03:00
|
|
|
metadata.major_device = major_from_encoded_device(dev);
|
|
|
|
|
metadata.minor_device = minor_from_encoded_device(dev);
|
2020-06-24 23: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 19:00:54 +02:00
|
|
|
auto child = TRY(RAMFSInode::try_create(fs(), metadata, *this));
|
2021-09-06 02:28:38 +02:00
|
|
|
TRY(add_child(*child, name, mode));
|
|
|
|
|
return child;
|
2020-06-24 23: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::add_child(Inode& child, StringView name, mode_t)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-02-23 20:42:32 +01:00
|
|
|
VERIFY(is_directory());
|
|
|
|
|
VERIFY(child.fsid() == fsid());
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2020-10-22 18:59:00 +02:00
|
|
|
if (name.length() > NAME_MAX)
|
2021-01-20 23:11:17 +01:00
|
|
|
return ENAMETOOLONG;
|
2020-10-22 18:59:00 +02:00
|
|
|
|
2022-01-01 22:18:59 +01:00
|
|
|
MutexLocker locker(m_inode_lock);
|
|
|
|
|
for (auto const& existing_child : m_children) {
|
|
|
|
|
if (existing_child.name->view() == name)
|
|
|
|
|
return EEXIST;
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-06 19:24:54 +02:00
|
|
|
auto name_kstring = TRY(KString::try_create(name));
|
2021-09-07 20:10:06 +02:00
|
|
|
// Balanced by `delete` in remove_child()
|
2022-01-01 22:18:59 +01: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 19:00:54 +02:00
|
|
|
auto* child_entry = new (nothrow) Child { move(name_kstring), static_cast<RAMFSInode&>(child) };
|
2021-07-18 13:47:18 +02:00
|
|
|
if (!child_entry)
|
|
|
|
|
return ENOMEM;
|
|
|
|
|
|
|
|
|
|
m_children.append(*child_entry);
|
2021-05-12 19:17:51 +00:00
|
|
|
did_add_child(child.identifier(), name);
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::remove_child(StringView name)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2021-02-23 20:42:32 +01:00
|
|
|
VERIFY(is_directory());
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2020-01-10 12:35:18 +01:00
|
|
|
if (name == "." || name == "..")
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2020-01-10 12:35:18 +01:00
|
|
|
|
2021-07-18 13:47:18 +02:00
|
|
|
auto* child = find_child_by_name(name);
|
|
|
|
|
if (!child)
|
2021-01-20 23:11:17 +01:00
|
|
|
return ENOENT;
|
2021-07-18 13:47:18 +02:00
|
|
|
|
|
|
|
|
auto child_id = child->inode->identifier();
|
|
|
|
|
child->inode->did_delete_self();
|
|
|
|
|
m_children.remove(*child);
|
2021-05-12 19:17:51 +00:00
|
|
|
did_remove_child(child_id, name);
|
2021-09-07 20:10:06 +02:00
|
|
|
// Balanced by `new` in add_child()
|
|
|
|
|
delete child;
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18: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 19:00:54 +02:00
|
|
|
ErrorOr<void> RAMFSInode::truncate(u64 size)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2021-02-23 20:42:32 +01:00
|
|
|
VERIFY(!is_directory());
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2022-09-09 06: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 19:00:54 +02: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 06: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 18:16:45 +03:00
|
|
|
}
|
|
|
|
|
m_metadata.size = size;
|
2021-12-28 12:33:27 +01:00
|
|
|
set_metadata_dirty(true);
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18:16:45 +03:00
|
|
|
}
|
|
|
|
|
|
2023-03-13 22:11:13 +01:00
|
|
|
ErrorOr<void> RAMFSInode::update_timestamps(Optional<UnixDateTime> atime, Optional<UnixDateTime> ctime, Optional<UnixDateTime> mtime)
|
2019-08-15 18:16:45 +03:00
|
|
|
{
|
2021-07-18 01:13:34 +02:00
|
|
|
MutexLocker locker(m_inode_lock);
|
2019-08-15 18:16:45 +03:00
|
|
|
|
2022-08-22 13:34:22 +02: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 21:02:32 +01:00
|
|
|
m_metadata.mtime = mtime.value();
|
2021-12-28 12:33:27 +01:00
|
|
|
set_metadata_dirty(true);
|
2021-11-08 00:51:39 +01:00
|
|
|
return {};
|
2019-08-15 18:16:45 +03:00
|
|
|
}
|
|
|
|
|
|
2020-02-16 01:27:42 +01:00
|
|
|
}
|