Samuka007/asterinas
1
0
Fork 0
mirror of https://github.com/asterinas/asterinas.git synced 2025-06-26 19:03:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix multiple documentation issues concerned by clippy

Browse Source
This commit is contained in:
Zhang Junyang
2024-06-19 08:15:23 +00:00
committed by Tate, Hongliang Tian
parent 4ba60271b1
commit 05533d7afd
14 changed files with 80 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
kernel/aster-nix/src/process/process/mod.rs
View File

@ -337,8 +337,8 @@ impl Process {
/// and moves the process to the session, returning the new session.
///
/// This method may return the following errors:
/// * `EPERM`, if the process is a process group leader, or some existing session
/// or process group has the same ID as the process.
/// * `EPERM`, if the process is a process group leader, or some existing session
/// or process group has the same ID as the process.
pub fn to_new_session(self: &Arc<Self>) -> Result<Arc<Session>> {
if self.is_session_leader() {
return Ok(self.session().unwrap());
@ -405,14 +405,14 @@ impl Process {
/// Moves the process to other process group.
///
/// * If the group already exists, the process and the group should belong to the same session.
/// * If the group does not exist, this method creates a new group for the process and move the
/// process to the group. The group is added to the session of the process.
/// * If the group already exists, the process and the group should belong to the same session.
/// * If the group does not exist, this method creates a new group for the process and move the
/// process to the group. The group is added to the session of the process.
///
/// This method may return `EPERM` in following cases:
/// * The process is session leader;
/// * The group already exists, but the group does not belong to the same session as the process;
/// * The group does not exist, but `pgid` is not equal to `pid` of the process.
/// * The process is session leader;
/// * The group already exists, but the group does not belong to the same session as the process;
/// * The group does not exist, but `pgid` is not equal to `pid` of the process.
pub fn to_other_group(self: &Arc<Self>, pgid: Pgid) -> Result<()> {
// if the process already belongs to the process group
if self.pgid() == pgid {

8
kernel/aster-nix/src/process/process_vm/init_stack/aux_vec.rs
View File

@ -10,10 +10,10 @@ use crate::prelude::*;
///
/// Here is a concise description of Auxiliary Vector from GNU's manual:
///
/// > When a program is executed, it receives information from the operating system
/// about the environment in which it is operating. The form of this information
/// is a table of key-value pairs, where the keys are from the set of ‘AT_’
/// values in elf.h.
/// > When a program is executed, it receives information from the operating system
/// > about the environment in which it is operating. The form of this information
/// > is a table of key-value pairs, where the keys are from the set of ‘AT_’
/// > values in elf.h.
#[allow(non_camel_case_types)]
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)]

8
kernel/aster-nix/src/vm/mod.rs
View File

@ -3,10 +3,10 @@
//! Virtual memory (VM).
//!
//! There are two primary VM abstractions:
//! * Virtual Memory Address Regions (VMARs) a type of capability that manages
//! user address spaces.
//! * Virtual Memory Objects (VMOs) are are a type of capability that
//! represents a set of memory pages.
//! * Virtual Memory Address Regions (VMARs) a type of capability that manages
//! user address spaces.
//! * Virtual Memory Objects (VMOs) are are a type of capability that
//! represents a set of memory pages.
//!
//! The concepts of VMARs and VMOs are originally introduced by
//! [Zircon](https://fuchsia.dev/fuchsia-src/reference/kernel_objects/vm_object).

10
kernel/aster-nix/src/vm/vmar/dyn_cap.rs
View File

@ -47,11 +47,11 @@ impl Vmar<Rights> {
/// # Access rights
///
/// This method requires the following access rights:
/// 1. The VMAR contains the rights corresponding to the memory permissions of
/// the mapping. For example, if `perms` contains `VmPerms::WRITE`,
/// then the VMAR must have the Write right.
/// 2. Similarly, the VMO contains the rights corresponding to the memory
/// permissions of the mapping.
/// 1. The VMAR contains the rights corresponding to the memory permissions of
/// the mapping. For example, if `perms` contains `VmPerms::WRITE`,
/// then the VMAR must have the Write right.
/// 2. Similarly, the VMO contains the rights corresponding to the memory
/// permissions of the mapping.
///
/// Memory permissions may be changed through the `protect` method,
/// which ensures that any updated memory permissions do not go beyond

12
kernel/aster-nix/src/vm/vmar/mod.rs
View File

@ -32,12 +32,12 @@ use crate::{prelude::*, vm::perms::VmPerms};
/// whose semantics are explained below.
///
/// The semantics of each access rights for VMARs are described below:
/// * The Dup right allows duplicating a VMAR and creating children out of
/// a VMAR.
/// * The Read, Write, Exec rights allow creating memory mappings with
/// readable, writable, and executable access permissions, respectively.
/// * The Read and Write rights allow the VMAR to be read from and written to
/// directly.
/// * The Dup right allows duplicating a VMAR and creating children out of
/// a VMAR.
/// * The Read, Write, Exec rights allow creating memory mappings with
/// readable, writable, and executable access permissions, respectively.
/// * The Read and Write rights allow the VMAR to be read from and written to
/// directly.
///
/// VMARs are implemented with two flavors of capabilities:
/// the dynamic one (`Vmar<Rights>`) and the static one (`Vmar<R: TRights>).

24
kernel/aster-nix/src/vm/vmar/vm_mapping.rs
View File

@ -384,12 +384,12 @@ impl VmMapping {
/// Trim a range from the mapping.
/// There are several cases.
/// 1. the trim_range is totally in the mapping. Then the mapping will split as two mappings.
/// 2. the trim_range covers the mapping. Then the mapping will be destroyed.
/// 3. the trim_range partly overlaps with the mapping, in left or right. Only overlapped part is trimmed.
/// If we create a mapping with a new map addr, we will add it to mappings_to_append.
/// If the mapping with map addr does not exist ever, the map addr will be added to mappings_to_remove.
/// Otherwise, we will directly modify self.
/// 1. the trim_range is totally in the mapping. Then the mapping will split as two mappings.
/// 2. the trim_range covers the mapping. Then the mapping will be destroyed.
/// 3. the trim_range partly overlaps with the mapping, in left or right. Only overlapped part is trimmed.
/// If we create a mapping with a new map addr, we will add it to mappings_to_append.
/// If the mapping with map addr does not exist ever, the map addr will be added to mappings_to_remove.
/// Otherwise, we will directly modify self.
pub fn trim_mapping(
self: &Arc<Self>,
trim_range: &Range<usize>,
@ -674,12 +674,12 @@ impl<R1, R2> VmarMapOptions<R1, R2> {
/// part of the mapping that is not backed by the VMO.
/// So you may wonder: what is the point of supporting such _oversized_
/// mappings? The reason is two-fold.
/// 1. VMOs are resizable. So even if a mapping is backed by a VMO whose
/// size is equal to that of the mapping initially, we cannot prevent
/// the VMO from shrinking.
/// 2. Mappings are not allowed to overlap by default. As a result,
/// oversized mappings can serve as a placeholder to prevent future
/// mappings from occupying some particular address ranges accidentally.
/// 1. VMOs are resizable. So even if a mapping is backed by a VMO whose
/// size is equal to that of the mapping initially, we cannot prevent
/// the VMO from shrinking.
/// 2. Mappings are not allowed to overlap by default. As a result,
/// oversized mappings can serve as a placeholder to prevent future
/// mappings from occupying some particular address ranges accidentally.
///
/// The default value is the size of the VMO.
pub fn size(mut self, size: usize) -> Self {

54
kernel/aster-nix/src/vm/vmo/mod.rs
View File

@ -31,38 +31,38 @@ use self::options::ChildType;
///
/// # Features
///
/// * **I/O interface.** A VMO provides read and write methods to access the
/// memory pages that it contain.
/// * **On-demand paging.** The memory pages of a VMO (except for _contiguous_
/// VMOs) are allocated lazily when the page is first accessed.
/// * **Tree structure.** Given a VMO, one can create a child VMO from it.
/// The child VMO can only access a subset of the parent's memory,
/// which is a good thing for the perspective of access control.
/// * **Copy-on-write (COW).** A child VMO may be created with COW semantics,
/// which prevents any writes on the child from affecting the parent
/// by duplicating memory pages only upon the first writes.
/// * **Access control.** As capabilities, VMOs restrict the
/// accessible range of memory and the allowed I/O operations.
/// * **Device driver support.** If specified upon creation, VMOs will be
/// backed by physically contiguous memory pages starting at a target address.
/// * **File system support.** By default, a VMO's memory pages are initially
/// all zeros. But if a VMO is attached to a pager (`Pager`) upon creation,
/// then its memory pages will be populated by the pager.
/// With this pager mechanism, file systems can easily implement page caches
/// with VMOs by attaching the VMOs to pagers backed by inodes.
/// * **I/O interface.** A VMO provides read and write methods to access the
/// memory pages that it contain.
/// * **On-demand paging.** The memory pages of a VMO (except for _contiguous_
/// VMOs) are allocated lazily when the page is first accessed.
/// * **Tree structure.** Given a VMO, one can create a child VMO from it.
/// The child VMO can only access a subset of the parent's memory,
/// which is a good thing for the perspective of access control.
/// * **Copy-on-write (COW).** A child VMO may be created with COW semantics,
/// which prevents any writes on the child from affecting the parent
/// by duplicating memory pages only upon the first writes.
/// * **Access control.** As capabilities, VMOs restrict the
/// accessible range of memory and the allowed I/O operations.
/// * **Device driver support.** If specified upon creation, VMOs will be
/// backed by physically contiguous memory pages starting at a target address.
/// * **File system support.** By default, a VMO's memory pages are initially
/// all zeros. But if a VMO is attached to a pager (`Pager`) upon creation,
/// then its memory pages will be populated by the pager.
/// With this pager mechanism, file systems can easily implement page caches
/// with VMOs by attaching the VMOs to pagers backed by inodes.
///
/// # Capabilities
///
/// As a capability, each VMO is associated with a set of access rights,
/// whose semantics are explained below.
///
/// * The Dup right allows duplicating a VMO and creating children out of
/// a VMO.
/// * The Read, Write, Exec rights allow creating memory mappings with
/// readable, writable, and executable access permissions, respectively.
/// * The Read and Write rights allow the VMO to be read from and written to
/// directly.
/// * The Write right allows resizing a resizable VMO.
/// * The Dup right allows duplicating a VMO and creating children out of
/// a VMO.
/// * The Read, Write, Exec rights allow creating memory mappings with
/// readable, writable, and executable access permissions, respectively.
/// * The Read and Write rights allow the VMO to be read from and written to
/// directly.
/// * The Write right allows resizing a resizable VMO.
///
/// VMOs are implemented with two flavors of capabilities:
/// the dynamic one (`Vmo<Rights>`) and the static one (`Vmo<R: TRights>).
@ -185,7 +185,7 @@ impl Pages {
/// `Vmo_` is the structure that actually manages the content of VMO.
/// Broadly speaking, there are two types of VMO:
/// 1. File-backed VMO: the VMO backed by a file and resides in the `PageCache`,
/// which includes a pager to provide it with actual pages.
/// which includes a pager to provide it with actual pages.
/// 2. Anonymous VMO: the VMO without a file backup, which does not have a pager.
pub(super) struct Vmo_ {
pager: Option<Arc<dyn Pager>>,