RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-26 16:47:45 +00:00
Code Issues Activity Actions

Kernel+SystemServer+Base: Introduce the RAMFS filesystem

Browse source 
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.
This commit is contained in:
Liav A 2023-01-28 19:00:54 +02:00 • committed by Andrew Kaster
parent fa637e29d2
commit ed67a877a3
12 changed files with 123 additions and 118 deletions
Download patch file Download diff file Expand all files Collapse all files

24
Documentation/Kernel/TmpFS.md → Documentation/Kernel/RAMFS.md
View file

@ -1,16 +1,16 @@
# `TmpFS` filesystem and its purposes
# `RAMFS` filesystem and its purposes
`TmpFS` is a RAM-backed filesystem. It is used to hold files and directories in the `/tmp` directory and
`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 `TmpFS` filesystem characteristics?
## What are the `RAMFS` filesystem characteristics?
`TmpFS` is a pure RAM-backed filesystem, which means all files and directories
actually live in memory, each in its own `TmpFS` instance in the kernel.
`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 `TmpFS` in its current design is very conservative about allocating virtual memory ranges
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 `TmpFS` code temporarily allocates a small virtual memory
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.
@ -24,10 +24,10 @@ 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 `TmpFS` work well for the `/dev` directory?
### Why does the `RAMFS` work well for the `/dev` directory?
To understand why `TmpFS` works reliably when mounted on `/dev`, we must understand
first what we did in the past and how `TmpFS` solves many of the issues with the previous design.
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
@ -54,7 +54,7 @@ The `DevFS` solution was short-lived, and was quickly replaced by the `DevTmpFS`
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 `TmpFS`
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
@ -65,6 +65,6 @@ in this document, but ultimately evolved to be flexible enough to work quite wel
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 `TmpFS`.
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.