From cbdb5f926c596efb013f6fa320f97be14fed6213 Mon Sep 17 00:00:00 2001 From: Annie Song Date: Fri, 5 May 2023 03:18:15 -0400 Subject: [PATCH] Documentation: Correct some typos found in kernel markdown files --- Documentation/Kernel/DevelopmentGuidelines.md | 2 +- Documentation/Kernel/GraphicsSubsystem.md | 2 +- Documentation/Kernel/ProcFSIndexing.md | 2 +- Documentation/Kernel/RAMFS.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/Kernel/DevelopmentGuidelines.md b/Documentation/Kernel/DevelopmentGuidelines.md index a330552cf83..b0af1e1102c 100644 --- a/Documentation/Kernel/DevelopmentGuidelines.md +++ b/Documentation/Kernel/DevelopmentGuidelines.md @@ -32,7 +32,7 @@ so the userland program could know about the situation and act accordingly. An exception to this is when there's simply no way to propagate the error code to the userland program. Maybe it's a `ATAPort` (in the IDE ATA code) that asynchronously tries to handle reading data from the harddrive, -but because of the async operation, we can't send the `errno` code back to userland, so we what we do is +but because of the async operation, we can't send the `errno` code back to userland, so what we do is to ensure that internal functions still use the `ErrorOr<>` return type, and in main calling function, we use other meaningful infrastructure utilities in the Kernel to indicate that the operation failed. diff --git a/Documentation/Kernel/GraphicsSubsystem.md b/Documentation/Kernel/GraphicsSubsystem.md index e747e6bbde3..60b5eec038d 100644 --- a/Documentation/Kernel/GraphicsSubsystem.md +++ b/Documentation/Kernel/GraphicsSubsystem.md @@ -19,7 +19,7 @@ from the framebuffer. # DisplayConnector Devices The Display Connector devices are an abstraction layer to what is essentially the -management layer of hardware display (commonly known as scanouts too) output connectors. +management layer of hardware display (commonly known as scanouts) output connectors. The idea of using such type of device was inspired by Linux, which has a struct called `drm_connector` as a base structure for other derived structures in the various Linux DRM drivers. diff --git a/Documentation/Kernel/ProcFSIndexing.md b/Documentation/Kernel/ProcFSIndexing.md index 482de3ed79d..9723a70910b 100644 --- a/Documentation/Kernel/ProcFSIndexing.md +++ b/Documentation/Kernel/ProcFSIndexing.md @@ -7,7 +7,7 @@ each `InodeIndex` actually represent a known object, so it is guaranteed to be the same always for global ProcFS objects. For process ID directories, once that process has been killed, its primary segment value is no longer valid and hence all sub-segments of it are not relevant anymore, but if the process is still alive, -it is guaranteed that accessing the same `InodeIndex` in regard to a object tied to +it is guaranteed that accessing the same `InodeIndex` in regard to an object tied to a process directory will provide the expected object. ## The goal - zero allocations when creating new process diff --git a/Documentation/Kernel/RAMFS.md b/Documentation/Kernel/RAMFS.md index 2eaf6d932df..fe96b157cbb 100644 --- a/Documentation/Kernel/RAMFS.md +++ b/Documentation/Kernel/RAMFS.md @@ -20,7 +20,7 @@ with very small overhead until actual IO is performed. 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 +Many test suites in the project leverage `/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.