ladybird/Documentation/Kernel/RAMFS.md
Liav A ed67a877a3 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-02-04 15:32:45 -07:00

4.6 KiB

RAMFS filesystem and its purposes

RAMFS is a RAM-backed filesystem. It is used to hold files and directories in the /tmp directory and device nodes in the /dev directory.

What are the RAMFS filesystem characteristics?

RAMFS is a pure RAM-backed filesystem, which means all files and directories actually live in memory, each in its own RAMFS instance in the kernel.

The RAMFS in its current design is very conservative about allocating virtual memory ranges for itself, and instead it uses the AnonymousVMObject object to hold physical pages containing data for its inodes. When doing actual IO, the RAMFS code temporarily allocates a small virtual memory Memory::Region to perform the task, which works quite well although it puts a strain on the virtual memory mapping code. The current design also ensures that fabricated huge files can be easily created in the filesystem with very small overhead until actual IO is performed.

The /tmp directory and its purposes

Currently, the /tmp directory is the place for facilitating the inter-process communication layer, with many Unix sockets nodes being present in the directory.

Many test suites in the project leverage the /tmp for placing their test files when trying to check the correctness of many system-related functionality. Other programs rely on /tmp for placing their temporary files to properly function.

Why does the RAMFS work well for the /dev directory?

To understand why RAMFS works reliably when mounted on /dev, we must understand first what we did in the past and how RAMFS solves many of the issues with the previous design.

At first, we didn't have any special filesystem mounted in /dev as the image build script generated all the required device nodes in /dev. This was quite sufficient in the early days of the project, where hardware support was extremely limited and of course hotplugging any kind of hardware was not even a consideration.

As the project grew larger and more hardware support was introduced, it became obvious that this "solution" was not future-proof. For example, if one user has two SATA drives connected to his computer, and another user has just one old IDE drive being used, then how should we support both cases? The answer was that each user could simply invoke the mknod utility to create device nodes. This solution meant that user interaction as well as a deep understanding of kernel internals was required to achieve a proper setup.

When it became apparent that another solution was needed, the DevFS filesystem was invented. The idea was plain simple - the DevFS is a read-only filesystem that only lists all present char and block devices. Permissions were hardcoded at known value, and modifying the filesystem (including adding subdirectories) was strictly prohibited. This solution was efficient in the sense of ensuring minimal user interaction for using device nodes in /dev. The shortcomings were strictly immutable filesystem layout and hardcoded permissions. Also, the filesystem implementation was specific to /dev, because no other mount in the system used this special filesystem, which meant it needed special test cases, etc.

The DevFS solution was short-lived, and was quickly replaced by the DevTmpFS solution. That new shiny filesystem was again specific to /dev, but it solved many of the issues DevFS suffered from - no more hardcoded permissions and now the design has flexible filesystem layout in its mindset. This was achieved by implementing from scratch a filesystem that resembles the RAMFS filesystem, but was different in one major aspect - only device nodes and directories are allowed to be in /dev. This strict requirement has been mandated to ensure the user doesn't accidentally put unrelated files in /dev. When the DevTmpFS was invented, it clearly needed userspace cooperation to create device nodes in /dev, so SystemServer was modified to create those during boot. The process of how SystemServer does that is not discussed in this document, but ultimately evolved to be flexible enough to work quite well.

Everything worked quite well, but there was still a prominent problem with DevTmpFS - it was an entire filesystem solution just for /dev and nobody else used it. Testing the filesystem was quite clunky and truthfully lacking from the beginning until its removal. To solve this problem, it was decided to stop using it, and instead just use RAMFS. To ensure the current behavior of disallowing regular files in /dev, a new mount flag called MS_NOREGULAR was invented, so it could be mounted with it.