mirror of
https://github.com/RGBCube/serenity
synced 2025-07-26 04:37:44 +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.
This commit is contained in:
parent
fa637e29d2
commit
ed67a877a3
12 changed files with 123 additions and 118 deletions
|
@ -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.
|
Loading…
Add table
Add a link
Reference in a new issue