Rename jinux to asterinas in documentation and code

framework/README.md

@@ -1,20 +1,20 @@
-# Jinux Framework
+# Asterinas Framework
 
-Jinux Framework is a Rust OS framework that facilitates the development of and innovation in OS kernels written in Rust.
+Asterinas Framework is a Rust OS framework that facilitates the development of and innovation in OS kernels written in Rust.
 
 ## An overview
 
-Jinux Framework provides a solid foundation for Rust developers to build their own OS kernels. While Jinux Framework origins from Jinux, the first ever framekernel, Jinux Framework is well suited for building OS kernels of any architecture, be it a framekernel, a monolithic kernel, or a microkernel.
+Asterinas Framework provides a solid foundation for Rust developers to build their own OS kernels. While Asterinas Framework origins from Asterinas, the first ever framekernel, Asterinas Framework is well suited for building OS kernels of any architecture, be it a framekernel, a monolithic kernel, or a microkernel.
 
-Jinux Framework offers the following key values.
+Asterinas Framework offers the following key values.
 
-1. **Lowering the entry bar for OS innovation.** Building an OS from scratch is not easy. Not to mention a novel one. Before adding any novel or interesting feature, an OS developer must first have something runnable, which must include basic functionalities for managing CPU, memory, and interrupts. Jinux Framework has laid this groundwork so that OS developers do not have to deal with the most low-level, error-prone, architecture-specific aspects of OS development themselves.
+1. **Lowering the entry bar for OS innovation.** Building an OS from scratch is not easy. Not to mention a novel one. Before adding any novel or interesting feature, an OS developer must first have something runnable, which must include basic functionalities for managing CPU, memory, and interrupts. Asterinas Framework has laid this groundwork so that OS developers do not have to deal with the most low-level, error-prone, architecture-specific aspects of OS development themselves.
 
-2. **Enhancing the memory safety of Rust OSes.** Jinux Framework encapsulates low-level, machine-oriented unsafe Rust code into high-level, machine-agnostic safe APIs. These APIs are carefully designed and implemented to be sound and minimal, ensuring the memory safety of any safe Rust callers. Our experience in building Jinux has shown that Jinux Framework is powerful enough to allow a feature-rich, Linux-compatible kernel to be completely written in safe Rust, including its device drivers.
+2. **Enhancing the memory safety of Rust OSes.** Asterinas Framework encapsulates low-level, machine-oriented unsafe Rust code into high-level, machine-agnostic safe APIs. These APIs are carefully designed and implemented to be sound and minimal, ensuring the memory safety of any safe Rust callers. Our experience in building Asterinas has shown that Asterinas Framework is powerful enough to allow a feature-rich, Linux-compatible kernel to be completely written in safe Rust, including its device drivers.
 
-3. **Promoting code reuse across Rust OS projects.** Shipped as crates, Rust code can be reused across projects---except when they are OSes. A crate that implements a feature or driver for OS A can hardly be reused by OS B because the crate must be [`no_std`](https://docs.rust-embedded.org/book/intro/no-std.html#summary) and depend on the infrastructure APIs provided by OS A, which are obviously different from that provided by OS B. This incompatibility problem can be resolved by Jinux Framework as it can serve as a common ground across different Rust OS projects, as long as they are built upon Jinux Framework.
+3. **Promoting code reuse across Rust OS projects.** Shipped as crates, Rust code can be reused across projects---except when they are OSes. A crate that implements a feature or driver for OS A can hardly be reused by OS B because the crate must be [`no_std`](https://docs.rust-embedded.org/book/intro/no-std.html#summary) and depend on the infrastructure APIs provided by OS A, which are obviously different from that provided by OS B. This incompatibility problem can be resolved by Asterinas Framework as it can serve as a common ground across different Rust OS projects, as long as they are built upon Asterinas Framework.
 
-4. **Boost productivity with user-mode development.** Traditionally, developing a kernel feature involves countless rounds of coding, failing, and rebooting on bare-metal or virtual machines, which is a painfully slow process. Jinux Framework accelerates the process by allowing high-level OS features like file systems and network stacks to be quickly tested in user mode, making the experience of OS development as smooth as that of application development. To support user-mode development, Jinux Framework is implemented for the Linux platform, in addition to bare-mental or virtual machine environments.
+4. **Boost productivity with user-mode development.** Traditionally, developing a kernel feature involves countless rounds of coding, failing, and rebooting on bare-metal or virtual machines, which is a painfully slow process. Asterinas Framework accelerates the process by allowing high-level OS features like file systems and network stacks to be quickly tested in user mode, making the experience of OS development as smooth as that of application development. To support user-mode development, Asterinas Framework is implemented for the Linux platform, in addition to bare-mental or virtual machine environments.
 
 ## Framework APIs
 

framework/aster-frame/src/arch/x86/boot/linux_boot/boot_params.rs

@@ -3,7 +3,7 @@
 //! The bootloader will deliver the address of the `BootParams` struct
 //! as the argument of the kernel entrypoint. So we must define a Linux
 //! ABI compatible struct in Rust, despite that most of the fields are
-//! currently not needed by Jinux.
+//! currently not needed by Asterinas.
 //!
 
 #[derive(Copy, Clone, Debug)]

framework/aster-frame/src/arch/x86/boot/linux_boot/mod.rs

@@ -152,5 +152,5 @@ unsafe extern "sysv64" fn __linux64_boot(params_ptr: *const boot_params::BootPar
         init_framebuffer_info,
         init_memory_regions,
     );
-    crate::boot::call_jinux_main();
+    crate::boot::call_aster_main();
 }

framework/aster-frame/src/arch/x86/boot/linux_boot/setup/src/header.S

@@ -9,8 +9,8 @@
 // Some of the fields filled with a 0xab* values should be filled
 // by the runner, which is the only tool after building and can
 // access the info of the payload.
-// Jinux will use only a few of these fields, and some of them
-// are filled by the loader and will be read by Jinux.
+// Asterinas will use only a few of these fields, and some of them
+// are filled by the loader and will be read by Asterinas.
 
 CODE32_START = 0x100000
 

framework/aster-frame/src/arch/x86/boot/linux_boot/setup/src/loader.rs

@@ -24,6 +24,6 @@ pub fn load_elf(file: &[u8]) -> u32 {
         }
     }
 
-    // Return the Linux 32-bit Boot Protocol entry point defined by Jinux.
+    // Return the Linux 32-bit Boot Protocol entry point defined by Asterinas.
     0x8001000
 }

framework/aster-frame/src/arch/x86/boot/linux_boot/setup/src/main.rs

@@ -9,7 +9,7 @@ use core::arch::{asm, global_asm};
 
 global_asm!(include_str!("header.S"));
 
-unsafe fn call_jinux_entrypoint(entrypoint: u32, boot_params_ptr: u32) -> ! {
+unsafe fn call_aster_entrypoint(entrypoint: u32, boot_params_ptr: u32) -> ! {
     asm!("mov esi, {}", in(reg) boot_params_ptr);
     asm!("mov eax, {}", in(reg) entrypoint);
     asm!("jmp eax");
@@ -34,7 +34,7 @@ pub extern "cdecl" fn _rust_setup_entry(boot_params_ptr: u32) -> ! {
     println!("[setup] entrypoint: {:#x}", entrypoint);
 
     // Safety: the entrypoint and the ptr is valid.
-    unsafe { call_jinux_entrypoint(entrypoint, boot_params_ptr) };
+    unsafe { call_aster_entrypoint(entrypoint, boot_params_ptr) };
 }
 
 #[panic_handler]

framework/aster-frame/src/arch/x86/boot/mod.rs

@@ -1,4 +1,4 @@
-//! The x86 boot module defines the entrypoints of Jinux and
+//! The x86 boot module defines the entrypoints of Asterinas and
 //! the corresponding headers for different x86 boot protocols.
 //!
 //! We directly support
@@ -9,7 +9,7 @@
 //!
 //! without any additional configurations.
 //!
-//! Jinux diffrentiates the boot protocol by the entry point
+//! Asterinas diffrentiates the boot protocol by the entry point
 //! chosen by the boot loader. In each entry point function,
 //! the universal callback registeration method from
 //! `crate::boot` will be called. Thus the initialization of

framework/aster-frame/src/arch/x86/boot/multiboot/mod.rs

@@ -339,5 +339,5 @@ unsafe extern "sysv64" fn __multiboot_entry(boot_magic: u32, boot_params: u64) -
         init_framebuffer_info,
         init_memory_regions,
     );
-    crate::boot::call_jinux_main();
+    crate::boot::call_aster_main();
 }

framework/aster-frame/src/arch/x86/boot/multiboot2/mod.rs

@@ -172,5 +172,5 @@ unsafe extern "sysv64" fn __multiboot2_entry(boot_magic: u32, boot_params: u64)
         init_framebuffer_info,
         init_memory_regions,
     );
-    crate::boot::call_jinux_main();
+    crate::boot::call_aster_main();
 }

framework/aster-frame/src/boot/kcmdline.rs

@@ -1,6 +1,6 @@
 //! The module to parse kernel command-line arguments.
 //!
-//! The format of the Jinux command line string conforms
+//! The format of the Asterinas command line string conforms
 //! to the Linux kernel command line rules:
 //!
 //! https://www.kernel.org/doc/html/v6.4/admin-guide/kernel-parameters.html

framework/aster-frame/src/boot/mod.rs

@@ -60,7 +60,7 @@ macro_rules! define_global_static_boot_arguments {
         ///
         /// For the introduction of a new boot protocol, the entry point could be a novel
         /// one. The entry point function should register all the boot initialization
-        /// methods before `jinux_main` is called. A boot initialization method takes a
+        /// methods before `aster_main` is called. A boot initialization method takes a
         /// reference of the global static boot information variable and initialize it,
         /// so that the boot information it represents could be accessed in the kernel
         /// anywhere.
@@ -104,16 +104,16 @@ pub fn init() {
 /// Call the framework-user defined entrypoint of the actual kernel.
 ///
 /// Any kernel that uses the aster-frame crate should define a function named
-/// `jinux_main` as the entrypoint.
-pub fn call_jinux_main() -> ! {
+/// `aster_main` as the entrypoint.
+pub fn call_aster_main() -> ! {
     #[cfg(not(ktest))]
     unsafe {
         // The entry point of kernel code, which should be defined by the package that
         // uses aster-frame.
         extern "Rust" {
-            fn jinux_main() -> !;
+            fn aster_main() -> !;
         }
-        jinux_main();
+        aster_main();
     }
     #[cfg(ktest)]
     {

framework/aster-frame/src/lib.rs

@@ -1,4 +1,4 @@
-//! The framework part of Jinux.
+//! The framework part of Asterinas.
 #![feature(alloc_error_handler)]
 #![feature(const_maybe_uninit_zeroed)]
 #![feature(const_mut_refs)]

framework/libs/ktest/src/lib.rs

@@ -1,9 +1,9 @@
-//! # The kernel mode testing framework of Jinux.
+//! # The kernel mode testing framework of Asterinas.
 //!
 //! `ktest` stands for kernel-mode testing framework. Its goal is to provide a
 //! `cargo test`-like experience for any `#![no_std]` bare metal crates.
 //!
-//! In Jinux, all the tests written in the source tree of the crates will be run
+//! In Asterinas, all the tests written in the source tree of the crates will be run
 //! immediately after the initialization of aster-frame. Thus you can use any
 //! feature provided by the frame including the heap allocator, etc.
 //!