beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-30 00:31:14 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity
ladybird/Kernel/FileSystem/ProcFS.h

103 lines
3.3 KiB
C
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 08:38:21 +00:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 08:38:21 +00:00
*/
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
#pragma once
Kernel: Add forward declaration header
2020-02-16 00:50:16 +00:00
#include <AK/HashMap.h>
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
#include <AK/Types.h>
Kernel: Move FS-related files into Kernel/FileSystem/
2019-04-03 10:25:24 +00:00
#include <Kernel/FileSystem/FileSystem.h>
Kernel: Move Inode to its own files.
2019-05-16 01:02:37 +00:00
#include <Kernel/FileSystem/Inode.h>
Kernel: Improve ProcFS behavior in low memory conditions When ProcFS could no longer allocate KBuffer objects to serve calls to read, it would just return 0, indicating EOF. This then triggered parsing errors because code assumed it read the file. Because read isn't supposed to return ENOMEM, change ProcFS to populate the file data upon file open or seek to the beginning. This also means that calls to open can now return ENOMEM if needed. This allows the caller to either be able to successfully open the file and read it, or fail to open it in the first place.
2020-09-17 19:51:09 +00:00
#include <Kernel/KBufferBuilder.h>
Add clang-format file Also run it across the whole tree to get everything using the One True Style. We don't yet run this in an automated fashion as it's a little slow, but there is a snippet to do so in makeall.sh.
2019-05-28 09:53:16 +00:00
#include <Kernel/Lock.h>
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
#include <Kernel/ProcessExposed.h>
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
Kernel: Move all code into the Kernel namespace
2020-02-16 00:27:42 +00:00
namespace Kernel {
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
class Process;
class ProcFSInode;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
class ProcFSDirectoryInode;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
Kernel: Rename FS => FileSystem This matches our common naming style better.
2021-07-10 22:20:38 +00:00
class ProcFS final : public FileSystem {
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
friend class ProcFSInode;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
friend class ProcFSDirectoryInode;
Add clang-format file Also run it across the whole tree to get everything using the One True Style. We don't yet run this in an automated fashion as it's a little slow, but there is a snippet to do so in makeall.sh.
2019-05-28 09:53:16 +00:00
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
public:
virtual ~ProcFS() override;
Kernel: Move ProcFS API towards OOM safety
2021-05-28 12:41:31 +00:00
static RefPtr<ProcFS> create();
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
virtual bool initialize() override;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
virtual const char* class_name() const override { return "ProcFS"; }
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
Kernel: Deemphasize inode identifiers These APIs were clearly modeled after Ext2FS internals, and make perfect sense in Ext2FS context. The new APIs are more generic, and map better to the semantics exported to the userspace, where inode identifiers only appear in stat() and readdir() output, but never in any input. This will also hopefully reduce the potential for races (see commit https://github.com/SerenityOS/serenity/commit/c44b4d61f350703fcf1bbd8f6e353b9c6c4210c2). Lastly, this makes it way more viable to implement a filesystem that only synthesizes its inodes lazily when queried, and destroys them when they are no longer in use. With inode identifiers being used to reference inodes, the only choice for such a filesystem is to persist any inode it has given out the identifier for, because it might be queried at any later time. With direct references to inodes, the filesystem will know when the last reference is dropped and the inode can be safely destroyed.
2020-06-24 20:35:56 +00:00
virtual NonnullRefPtr<Inode> root_inode() const override;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
private:
ProcFS();
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
NonnullRefPtr<ProcFSDirectoryInode> m_root_inode;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
};
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
class ProcFSInode : public Inode {
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
friend class ProcFS;
Add clang-format file Also run it across the whole tree to get everything using the One True Style. We don't yet run this in an automated fashion as it's a little slow, but there is a snippet to do so in makeall.sh.
2019-05-28 09:53:16 +00:00
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
public:
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
static NonnullRefPtr<ProcFSInode> create(const ProcFS&, const ProcFSExposedComponent&);
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
virtual ~ProcFSInode() override;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
StringView name() const;
protected:
ProcFSInode(const ProcFS&, const ProcFSExposedComponent&);
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
// ^Inode
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
virtual KResult attach(FileDescription& description) override;
Kernel: Remove various other uses of ssize_t
2021-06-16 14:44:15 +00:00
virtual KResultOr<size_t> read_bytes(off_t, size_t, UserOrKernelBuffer& buffer, FileDescription*) const override;
Kernel: Rename FS => FileSystem This matches our common naming style better.
2021-07-10 22:20:38 +00:00
virtual KResult traverse_as_directory(Function<bool(FileSystem::DirectoryEntryView const&)>) const override;
Kernel: Make Inode::lookup() return a RefPtr<Inode> Previously this API would return an InodeIdentifier, which meant that there was a race in path resolution where an inode could be unlinked in between finding the InodeIdentifier for a path component, and actually resolving that to an Inode object. Attaching a test that would quickly trip an assertion before. Test: Kernel/path-resolution-race.cpp
2020-02-01 08:23:46 +00:00
virtual RefPtr<Inode> lookup(StringView name) override;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
virtual void flush_metadata() override;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
virtual InodeMetadata metadata() const override;
Kernel: Remove various other uses of ssize_t
2021-06-16 14:44:15 +00:00
virtual KResultOr<size_t> write_bytes(off_t, size_t, const UserOrKernelBuffer& buffer, FileDescription*) override;
Kernel: Deemphasize inode identifiers These APIs were clearly modeled after Ext2FS internals, and make perfect sense in Ext2FS context. The new APIs are more generic, and map better to the semantics exported to the userspace, where inode identifiers only appear in stat() and readdir() output, but never in any input. This will also hopefully reduce the potential for races (see commit https://github.com/SerenityOS/serenity/commit/c44b4d61f350703fcf1bbd8f6e353b9c6c4210c2). Lastly, this makes it way more viable to implement a filesystem that only synthesizes its inodes lazily when queried, and destroys them when they are no longer in use. With inode identifiers being used to reference inodes, the only choice for such a filesystem is to persist any inode it has given out the identifier for, because it might be queried at any later time. With direct references to inodes, the filesystem will know when the last reference is dropped and the inode can be safely destroyed.
2020-06-24 20:35:56 +00:00
virtual KResultOr<NonnullRefPtr<Inode>> create_child(const String& name, mode_t, dev_t, uid_t, gid_t) override;
virtual KResult add_child(Inode&, const StringView& name, mode_t) override;
Kernel: Use StringView more in Inode and subclasses.
2019-06-09 08:25:19 +00:00
virtual KResult remove_child(const StringView& name) override;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
virtual void did_seek(FileDescription&, off_t) override;
Kernel: Make Inode::directory_entry_count errors observable. Certain implementations of Inode::directory_entry_count were calling functions which returned errors, but had no way of surfacing them. Switch the return type to KResultOr<size_t> and start observing these error paths.
2020-08-05 08:00:18 +00:00
virtual KResultOr<size_t> directory_entry_count() const override;
Kernel: Add KResult and KResultOr<T> classes. The idea here is to combine a potential syscall error code with an arbitrary type in the case of success. I feel like this will end up much less error prone than returning some arbitrary type that kinda sorta has bool semantics (but sometimes not really) and passing the error through an out-param. This patch only converts a few syscalls to using it. More to come.
2019-02-25 19:47:56 +00:00
virtual KResult chmod(mode_t) override;
Add chown() syscall and a simple /bin/chown program.
2019-02-27 11:32:53 +00:00
virtual KResult chown(uid_t, gid_t) override;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
virtual KResult truncate(u64) override;
NonnullRefPtr<ProcFSExposedComponent> m_associated_component;
};
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
class ProcFSLinkInode : public ProcFSInode {
friend class ProcFS;
Kernel: Improve ProcFS behavior in low memory conditions When ProcFS could no longer allocate KBuffer objects to serve calls to read, it would just return 0, indicating EOF. This then triggered parsing errors because code assumed it read the file. Because read isn't supposed to return ENOMEM, change ProcFS to populate the file data upon file open or seek to the beginning. This also means that calls to open can now return ENOMEM if needed. This allows the caller to either be able to successfully open the file and read it, or fail to open it in the first place.
2020-09-17 19:51:09 +00:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
public:
static NonnullRefPtr<ProcFSLinkInode> create(const ProcFS&, const ProcFSExposedComponent&);
ProcFS: Fix /proc/PID/* hardening bypass This enabled trivial ASLR bypass for non-dumpable programs by simply opening /proc/PID/vm before exec'ing. We now hold the target process's ptrace lock across the refresh/write operations, and deny access if the process is non-dumpable. The lock is necessary to prevent a TOCTOU race on Process::is_dumpable() while the target is exec'ing. Fixes #5270.
2021-02-19 08:41:35 +00:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
protected:
ProcFSLinkInode(const ProcFS&, const ProcFSExposedComponent&);
virtual InodeMetadata metadata() const override;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 11:33:11 +00:00
};
ProcFS: Implement symlink magic
2020-01-15 11:05:02 +00:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
class ProcFSDirectoryInode : public ProcFSInode {
friend class ProcFS;
ProcFS: Implement symlink magic
2020-01-15 11:05:02 +00:00
public:
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
static NonnullRefPtr<ProcFSDirectoryInode> create(const ProcFS&, const ProcFSExposedComponent&);
virtual ~ProcFSDirectoryInode() override;
ProcFS: Implement symlink magic
2020-01-15 11:05:02 +00:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
protected:
ProcFSDirectoryInode(const ProcFS&, const ProcFSExposedComponent&);
ProcFS: Implement symlink magic
2020-01-15 11:05:02 +00:00
// ^Inode
virtual InodeMetadata metadata() const override;
Kernel: Rename FS => FileSystem This matches our common naming style better.
2021-07-10 22:20:38 +00:00
virtual KResult traverse_as_directory(Function<bool(FileSystem::DirectoryEntryView const&)>) const override;
Kernel: Make Inode::lookup() return a RefPtr<Inode> Previously this API would return an InodeIdentifier, which meant that there was a race in path resolution where an inode could be unlinked in between finding the InodeIdentifier for a path component, and actually resolving that to an Inode object. Attaching a test that would quickly trip an assertion before. Test: Kernel/path-resolution-race.cpp
2020-02-01 08:23:46 +00:00
virtual RefPtr<Inode> lookup(StringView name) override;
Kernel: Make Inode::directory_entry_count errors observable. Certain implementations of Inode::directory_entry_count were calling functions which returned errors, but had no way of surfacing them. Switch the return type to KResultOr<size_t> and start observing these error paths.
2020-08-05 08:00:18 +00:00
virtual KResultOr<size_t> directory_entry_count() const override;
ProcFS: Implement symlink magic
2020-01-15 11:05:02 +00:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 01:23:58 +00:00
ProcFS& m_parent_fs;
ProcFS: Implement symlink magic
2020-01-15 11:05:02 +00:00
};
Kernel: Move all code into the Kernel namespace
2020-02-16 00:27:42 +00:00
}
Reference in a new issue Copy permalink