reorgnize current codes and rename project to jinux

.gitattributes

@@ -1,8 +1,8 @@
-src/kxos-user/hello_world/hello_world filter=lfs diff=lfs merge=lfs -text
-src/kxos-user/fork/fork filter=lfs diff=lfs merge=lfs -text
-src/kxos-user/hello_c/hello filter=lfs diff=lfs merge=lfs -text
-src/kxos-user/execve/execve filter=lfs diff=lfs merge=lfs -text
-src/kxos-user/execve/hello filter=lfs diff=lfs merge=lfs -text
-src/kxos-user/fork_c/fork filter=lfs diff=lfs merge=lfs -text
-src/kxos-user/signal_c/signal_test filter=lfs diff=lfs merge=lfs -text
-src/kxos-user/busybox/busybox filter=lfs diff=lfs merge=lfs -text
+src/apps/hello_world/hello_world filter=lfs diff=lfs merge=lfs -text
+src/apps/fork/fork filter=lfs diff=lfs merge=lfs -text
+src/appshello_c/hello filter=lfs diff=lfs merge=lfs -text
+src/apps/execve/execve filter=lfs diff=lfs merge=lfs -text
+src/apps/execve/hello filter=lfs diff=lfs merge=lfs -text
+src/apps/fork_c/fork filter=lfs diff=lfs merge=lfs -text
+src/apps/signal_c/signal_test filter=lfs diff=lfs merge=lfs -text
+src/apps/busybox/busybox filter=lfs diff=lfs merge=lfs -text

README.md

@@ -1,26 +1,26 @@
-# KxOS
+# Jinux
 
-KxOS is a modern and secure OS kernel written in Rust, especially suitable for Trusted Execution Environments (TEEs)
+Jinux is a modern and secure OS kernel written in Rust, especially suitable for Trusted Execution Environments (TEEs)
 
 ## Design Goals
 
-**1. Security by design.** Security is our top priority in the design of KxOS. As such, we adopt the widely acknowledged security best practice of [least privilege principle](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and enforce it in a fashion that leverages the full strengths of Rust. To do so, we partition KxOS into two halves: a _privileged_ OS core and _unprivileged_ OS components. As a result, we can write the OS components almost entirely in _safe_ Rust, while taking extra cautions with the _unsafe_ Rust code in the OS core. Furthermore, we propose the idea of _everything-is-a-capability_, which elevates the status of [capabilities](https://en.wikipedia.org/wiki/Capability-based_security) to the level of a ubiquitous security primitive used throughout the OS. We make novel use of Rust's advanced features (e.g., [type-level programming](https://willcrichton.net/notes/type-level-programming/)) to make capabilities more accessible and efficient. The net result is improved security and uncompromised performance.
+**1. Security by design.** Security is our top priority in the design of Jinux. As such, we adopt the widely acknowledged security best practice of [least privilege principle](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and enforce it in a fashion that leverages the full strengths of Rust. To do so, we partition Jinux into two halves: a _privileged_ OS core and _unprivileged_ OS components. As a result, we can write the OS components almost entirely in _safe_ Rust, while taking extra cautions with the _unsafe_ Rust code in the OS core. Furthermore, we propose the idea of _everything-is-a-capability_, which elevates the status of [capabilities](https://en.wikipedia.org/wiki/Capability-based_security) to the level of a ubiquitous security primitive used throughout the OS. We make novel use of Rust's advanced features (e.g., [type-level programming](https://willcrichton.net/notes/type-level-programming/)) to make capabilities more accessible and efficient. The net result is improved security and uncompromised performance.
 
-**2. Trustworthy OS-level virtualization.** OS-level virtualization mechanisms (like Linux's cgroups and namespaces) enable containers, a more lightweight and arguably more popular alternative to virtual machines (VMs). But there is one problem with containers: they are not as secure as VMs (see [StackExchange](https://security.stackexchange.com/questions/169642/what-makes-docker-more-secure-than-vms-or-bare-metal), [LWN](https://lwn.net/Articles/796700/), and [AWS](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-tasks-containers.html)). There is a real risk that malicious containers may exploit privilege escalation bugs in the OS kernel to attack the host. [A study](https://dl.acm.org/doi/10.1145/3274694.3274720) found that 11 out of 88 kernel exploits are effective in breaking the container sandbox. The seemingly inherent insecurity of OS kernels leads to a new breed of container implementations (e.g., [Kata](https://katacontainers.io/) and [gVisor](https://gvisor.dev/)) that are based on VMs, instead of kernels, for isolation and sandboxing. We argue that this unfortunate retreat from OS-level virtualization to VM-based one is unwarranted---if the OS kernels are secure enough. And this is exactly what we plan to achieve with KxOS. We aim to provide a trustworthy OS-level virtualization mechanism on KxOS.
+**2. Trustworthy OS-level virtualization.** OS-level virtualization mechanisms (like Linux's cgroups and namespaces) enable containers, a more lightweight and arguably more popular alternative to virtual machines (VMs). But there is one problem with containers: they are not as secure as VMs (see [StackExchange](https://security.stackexchange.com/questions/169642/what-makes-docker-more-secure-than-vms-or-bare-metal), [LWN](https://lwn.net/Articles/796700/), and [AWS](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-tasks-containers.html)). There is a real risk that malicious containers may exploit privilege escalation bugs in the OS kernel to attack the host. [A study](https://dl.acm.org/doi/10.1145/3274694.3274720) found that 11 out of 88 kernel exploits are effective in breaking the container sandbox. The seemingly inherent insecurity of OS kernels leads to a new breed of container implementations (e.g., [Kata](https://katacontainers.io/) and [gVisor](https://gvisor.dev/)) that are based on VMs, instead of kernels, for isolation and sandboxing. We argue that this unfortunate retreat from OS-level virtualization to VM-based one is unwarranted---if the OS kernels are secure enough. And this is exactly what we plan to achieve with Jinux. We aim to provide a trustworthy OS-level virtualization mechanism on Jinux.
 
-**3. High-velocity development.** Traditional OS kernels like Linux are hard to develop, test, and debug. Kernel development involves countless rounds of programming, failing, and rebooting on bare-metal or virtual machines. This way of life is unproductive and painful. Such a pain point is also recognized and partially addressed by [research work](https://www.usenix.org/conference/fast21/presentation/miller), but we think we can do more. In this spirit, we design the OS core to provide high-level APIs that are largely independent of the underlying hardware and implement it with two targets: one target is as part of a regular OS in kernel space and the other is as a library OS in user space. This way, all the OS components of KxOS, which are stacked above the OS core, can be developed, tested, and debugged in user space, which is more friendly to developers than kernel space.
+**3. High-velocity development.** Traditional OS kernels like Linux are hard to develop, test, and debug. Kernel development involves countless rounds of programming, failing, and rebooting on bare-metal or virtual machines. This way of life is unproductive and painful. Such a pain point is also recognized and partially addressed by [research work](https://www.usenix.org/conference/fast21/presentation/miller), but we think we can do more. In this spirit, we design the OS core to provide high-level APIs that are largely independent of the underlying hardware and implement it with two targets: one target is as part of a regular OS in kernel space and the other is as a library OS in user space. This way, all the OS components of Jinux, which are stacked above the OS core, can be developed, tested, and debugged in user space, which is more friendly to developers than kernel space.
 
-**4. High-fidelity Linux ABI.** An OS without usable applications is useless. So we believe it is important for KxOS to fit in an established and thriving ecosystem of software, such as the one around Linux. This is why we conclude that KxOS should aim at implementing high-fidelity Linux ABI, including the system calls, the proc file system, etc. 
+**4. High-fidelity Linux ABI.** An OS without usable applications is useless. So we believe it is important for Jinux to fit in an established and thriving ecosystem of software, such as the one around Linux. This is why we conclude that Jinux should aim at implementing high-fidelity Linux ABI, including the system calls, the proc file system, etc. 
 
 ## Architecture
 
-Here is an overview of the architecture of KxOS.
+Here is an overview of the architecture of Jinux.
 
 ![architecture overview](docs/figures/arch_overview.png)
 
 ## Roadmap
 
-While there is nothing revolutionary in KxOS, it does explore some new design points in constructing secure Rust OSes. To minimize the risks of the project, we plan to move towards Minimal Viable Product (MVP) in iterations.
+While there is nothing revolutionary in Jinux, it does explore some new design points in constructing secure Rust OSes. To minimize the risks of the project, we plan to move towards Minimal Viable Product (MVP) in iterations.
 
 - [ ] Iteration 1: Build a minimal OS core runnable in both VMs and user space.
 - [ ] Iteration 2: Build a minimal set of OS components to run simple programs

docs/README.md

@@ -1,4 +1,4 @@
-# KxOS Documentation
+# Jinux Documentation
 
 The documentation is rendered as a book with [mdBook](https://rust-lang.github.io/mdBook/),
 which can be installed with `cargo`.

docs/book.toml

@@ -3,7 +3,7 @@ authors = ["Tate, Hongliang Tian"]
 language = "en"
 multilingual = false
 src = "src"
-title = "KxOS: A Secure, Fast, and Modern OS in Rust"
+title = "Jinux: A Secure, Fast, and Modern OS in Rust"
 
 [rust]
 edition = "2021"

docs/src/README.md

@@ -14,7 +14,7 @@
 
 # Introduction
 
-This document describes KxOS, a secure, fast, and modern OS written in Rust.
+This document describes Jinux, a secure, fast, and modern OS written in Rust.
 
 As the project is a work in progress, this document is by no means complete.
 Despite the incompleteness, this evolving document serves several important purposes:
@@ -50,7 +50,7 @@ OSes, e.g., [Kerla](https://github.com/nuta/kerla),
 and [zCore](https://github.com/rcore-os/zCore). Despite their varying degrees of
 success, none of them are general-purpose, industrial-strength OSes that are or
 will ever be competitive with Linux. Eventually, a winner will emerge out of this
-market of Rust OSes, and KxOS is our bet for this competition.
+market of Rust OSes, and Jinux is our bet for this competition.
 
 Second, Rust OSes are a perfect fit for
 [Trusted Execution Environments (TEEs)](https://en.wikipedia.org/wiki/Trusted_execution_environment).
@@ -79,24 +79,24 @@ relational databases:
 [Oracle and IBM are losing ground as Chinese vendors catch up with their US counterparts](https://www.theregister.com/2022/07/06/international_database_vendors_are_losing/).
 Can such success stories be repeated in the field of OSes? I think so.
 There are some China's home-grown OSes like [openKylin](https://www.openkylin.top/index.php?lang=en), but all of them are based on Linux and lack a self-developed
-OS _kernel_. The long-term goal of KxOS is to fill this key missing core of the home-grown OSes.
+OS _kernel_. The long-term goal of Jinux is to fill this key missing core of the home-grown OSes.
 
 ## Architecture Overview
 
-Here is an overview of the architecture of KxOS.
+Here is an overview of the architecture of Jinux.
 
 ![architecture overview](images/arch_overview.png)
 
 ## Features
 
-**1. Security by design.** Security is our top priority in the design of KxOS. As such, we adopt the widely acknowledged security best practice of [least privilege principle](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and enforce it in a fashion that leverages the full strengths of Rust. To do so, we partition KxOS into two halves: a _privileged_ OS core and _unprivileged_ OS components. All OS components are written entirely in _safe_ Rust and only the privileged OS core
+**1. Security by design.** Security is our top priority in the design of Jinux. As such, we adopt the widely acknowledged security best practice of [least privilege principle](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and enforce it in a fashion that leverages the full strengths of Rust. To do so, we partition Jinux into two halves: a _privileged_ OS core and _unprivileged_ OS components. All OS components are written entirely in _safe_ Rust and only the privileged OS core
 is allowed to have _unsafe_ Rust code. Furthermore, we propose the idea of _everything-is-a-capability_, which elevates the status of [capabilities](https://en.wikipedia.org/wiki/Capability-based_security) to the level of a ubiquitous security primitive used throughout the OS. We make novel use of Rust's advanced features (e.g., [type-level programming](https://willcrichton.net/notes/type-level-programming/)) to make capabilities more accessible and efficient. The net result is improved security and uncompromised performance.
 
-**2. Trustworthy OS-level virtualization.** OS-level virtualization mechanisms (like Linux's cgroups and namespaces) enable containers, a more lightweight and arguably more popular alternative to virtual machines (VMs). But there is one problem with containers: they are not as secure as VMs (see [StackExchange](https://security.stackexchange.com/questions/169642/what-makes-docker-more-secure-than-vms-or-bare-metal), [LWN](https://lwn.net/Articles/796700/), and [AWS](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-tasks-containers.html)). There is a real risk that malicious containers may exploit privilege escalation bugs in the OS kernel to attack the host. [A study](https://dl.acm.org/doi/10.1145/3274694.3274720) found that 11 out of 88 kernel exploits are effective in breaking the container sandbox. The seemingly inherent insecurity of OS kernels leads to a new breed of container implementations (e.g., [Kata](https://katacontainers.io/) and [gVisor](https://gvisor.dev/)) that are based on VMs, instead of kernels, for isolation and sandboxing. We argue that this unfortunate retreat from OS-level virtualization to VM-based one is unwarranted---if the OS kernels are secure enough. And this is exactly what we plan to achieve with KxOS. We aim to provide a trustworthy OS-level virtualization mechanism on KxOS.
+**2. Trustworthy OS-level virtualization.** OS-level virtualization mechanisms (like Linux's cgroups and namespaces) enable containers, a more lightweight and arguably more popular alternative to virtual machines (VMs). But there is one problem with containers: they are not as secure as VMs (see [StackExchange](https://security.stackexchange.com/questions/169642/what-makes-docker-more-secure-than-vms-or-bare-metal), [LWN](https://lwn.net/Articles/796700/), and [AWS](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-tasks-containers.html)). There is a real risk that malicious containers may exploit privilege escalation bugs in the OS kernel to attack the host. [A study](https://dl.acm.org/doi/10.1145/3274694.3274720) found that 11 out of 88 kernel exploits are effective in breaking the container sandbox. The seemingly inherent insecurity of OS kernels leads to a new breed of container implementations (e.g., [Kata](https://katacontainers.io/) and [gVisor](https://gvisor.dev/)) that are based on VMs, instead of kernels, for isolation and sandboxing. We argue that this unfortunate retreat from OS-level virtualization to VM-based one is unwarranted---if the OS kernels are secure enough. And this is exactly what we plan to achieve with Jinux. We aim to provide a trustworthy OS-level virtualization mechanism on Jinux.
 
-**3. Fast user-mode development.** Traditional OS kernels like Linux are hard to develop, test, and debug. Kernel development involves countless rounds of programming, failing, and rebooting on bare-metal or virtual machines. This way of life is unproductive and painful. Such a pain point is also recognized and partially addressed by [research work](https://www.usenix.org/conference/fast21/presentation/miller), but we think we can do more. In this spirit, we design the OS core to provide high-level APIs that are largely independent of the underlying hardware and implement it with two targets: one target is as part of a regular OS in kernel space and the other is as a library OS in user space. This way, all the OS components of KxOS, which are stacked above the OS core, can be developed, tested, and debugged in user space, which is more friendly to developers than kernel space.
+**3. Fast user-mode development.** Traditional OS kernels like Linux are hard to develop, test, and debug. Kernel development involves countless rounds of programming, failing, and rebooting on bare-metal or virtual machines. This way of life is unproductive and painful. Such a pain point is also recognized and partially addressed by [research work](https://www.usenix.org/conference/fast21/presentation/miller), but we think we can do more. In this spirit, we design the OS core to provide high-level APIs that are largely independent of the underlying hardware and implement it with two targets: one target is as part of a regular OS in kernel space and the other is as a library OS in user space. This way, all the OS components of Jinux, which are stacked above the OS core, can be developed, tested, and debugged in user space, which is more friendly to developers than kernel space.
 
-**4. High-fidelity Linux ABI.** An OS without usable applications is useless. So we believe it is important for KxOS to fit in an established and thriving ecosystem of software, such as the one around Linux. This is why we conclude that KxOS should aim at implementing high-fidelity Linux ABI, including the system calls, the proc file system, etc.
+**4. High-fidelity Linux ABI.** An OS without usable applications is useless. So we believe it is important for Jinux to fit in an established and thriving ecosystem of software, such as the one around Linux. This is why we conclude that Jinux should aim at implementing high-fidelity Linux ABI, including the system calls, the proc file system, etc.
 
 **5. TEEs as top-tier targets.** (Todo)
 

docs/src/capabilities/README.md

@@ -20,12 +20,12 @@ capabilities in a limited fashion, mostly as a means to limit the access from
 external users (e.g., via syscall), rather than a mechanism to enforce advanced
 security policies internally (e.g., module-level isolation).
 
-So we ask this question: is it possible to use capabilities as a _ubitiquous_ security primitive throughout KxOS to enhance the security and robustness of the
+So we ask this question: is it possible to use capabilities as a _ubitiquous_ security primitive throughout Jinux to enhance the security and robustness of the
 OS? Specifically, we propose a new principle called "_everything is a capability_".
 Here, "everything" refers to any type of OS resource, internal or external alike.
 In traditional OSes, treating everything as a capability is unrewarding 
 because (1) capabilities themselves are unreliable due to memory safety problems
-, and (2) capabilities are no free lunch as they incur memory and CPU overheads. But these arguments may no longer stand in a well-designed Rust OS like KxOS.
+, and (2) capabilities are no free lunch as they incur memory and CPU overheads. But these arguments may no longer stand in a well-designed Rust OS like Jinux.
 Because the odds of memory safety bugs are minimized and 
 advanced Rust features like type-level programming allow us to implement
 capabilities as a zero-cost abstraction.

docs/src/capabilities/zero_cost_capabilities.md

@@ -1,6 +1,6 @@
 # Zero-Cost Capabilities
 
-To strengthen the security of KxOS, we aim to implement all kinds of OS resources
+To strengthen the security of Jinux, we aim to implement all kinds of OS resources
 as capabilities. As the capabilities are going to be used throughout the OS,
 it is highly desirable to minimize their costs. For this purpose,
 we want to implement capabilities as a _zero-cost abstraction_.
@@ -351,7 +351,7 @@ mod test {
 
 ### Implement access rights with typeflags
 
-The `kxos-rights/lib.rs` file implements access rights.
+The `Jinux-rights/lib.rs` file implements access rights.
 
 ```rust
 //! Access rights.
@@ -376,7 +376,7 @@ typeflags! {
 }
 ```
 
-The `kxos-rights-proc/lib.rs` file implements the `require` procedural macro.
+The `Jinux-rights-proc/lib.rs` file implements the `require` procedural macro.
 See the channel capability example later for how `require` is used.
 
 ```rust

docs/src/privilege_separation/README.md

@@ -1,15 +1,15 @@
 # Privilege Separation
 
-One fundamental design goal of KxOS is to support _privilege separation_, i.e., the separation between the privileged OS core and the unprivileged OS components. The privileged portion is allowed to use `unsafe` keyword to carry out dangerous tasks like accessing CPU registers, manipulating stack frames, and doing MMIO or PIO. In contrast, the unprivileged portion, which forms the majority of the OS, must be free from `unsafe` code. With privilege separation, the memory safety of KxOS can be boiled down to the correctness of the privileged OS core, regardless of the correctness of the unprivileged OS components, thus reducing the size of TCB  significantly.
+One fundamental design goal of Jinux is to support _privilege separation_, i.e., the separation between the privileged OS core and the unprivileged OS components. The privileged portion is allowed to use `unsafe` keyword to carry out dangerous tasks like accessing CPU registers, manipulating stack frames, and doing MMIO or PIO. In contrast, the unprivileged portion, which forms the majority of the OS, must be free from `unsafe` code. With privilege separation, the memory safety of Jinux can be boiled down to the correctness of the privileged OS core, regardless of the correctness of the unprivileged OS components, thus reducing the size of TCB  significantly.
 
 To put privilege separation into perspective, let's compare the architectures
-of the monolithic kernels, microkernels, and KxOS.
+of the monolithic kernels, microkernels, and Jinux.
 
 ![Arch comparison](../images/arch_comparison.png)
 
 The diagram above highlights the characteristics of different OS architectures 
 in terms of communication overheads and the TCB for memory safety.
-Thanks to privilege separation, KxOS promises the benefit of being _as safe as a microkernel and as fast as a monolithic kernel_.
+Thanks to privilege separation, Jinux promises the benefit of being _as safe as a microkernel and as fast as a monolithic kernel_.
 
 Privilege separation is an interesting research problem, prompting us to 
 answer a series of technical questions.

docs/src/privilege_separation/pci_virtio_drivers.md

@@ -22,7 +22,7 @@ Here are some of the elements in PCI-based Virtio devices that may involve `unsa
 ### Privileged part
 
 ```rust
-// file: kxos-core-libs/pci-io-port/lib.rs
+// file: jinux-core-libs/pci-io-port/lib.rs
 use x86::IoPort;
 
 /// The I/O port to write an address in the PCI 
@@ -49,7 +49,7 @@ pub const PCI_DATA_PORT: IoPort<u32> = {
 ### Unprivileged part
 
 ```rust
-// file: kxos-comps/pci/lib.rs
+// file: jinux-comps/pci/lib.rs
 use pci_io_port::{PCI_ADDR_PORT, PCI_DATA_PORT};
 
 /// The PCI configuration space, which enables the discovery,
@@ -128,7 +128,7 @@ pub struct PciCapabilities {
 Most code of Virtio drivers can be unprivileged thanks to the abstractions of `VmPager` and `VmCell` provided by the OS core.
 
 ```rust
-// file: kxos-comp-libs/virtio/transport.rs
+// file: jinux-comp-libs/virtio/transport.rs
 
 /// The transport layer for configuring a Virtio device.
 pub struct VirtioTransport {

docs/src/privilege_separation/syscall_workflow.md

@@ -138,7 +138,7 @@ impl<T, P: Write> UserPtr<T, P> {
 }
 ```
 
-The examples reveal two important considerations in designing KxOS:
+The examples reveal two important considerations in designing Jinux:
 1. Exposing _truly_ safe APIs. The privileged OS core must expose _truly safe_ APIs: however buggy or silly the unprivileged OS components may be written, they must _not_ cause undefined behaviors.
 2. Handling _arbitrary_ pointers safely. The safe API of the OS core must provide a safe way to deal with arbitrary pointers.
 
@@ -146,15 +146,15 @@ With the two points in mind, let's get back to our main goal of privilege separa
 
 ## Code organization with privilege separation
 
-Our first step is to separate privileged and unprivileged code in the codebase of KxOS. For our purpose of demonstrating a syscall handling framework, a minimal codebase may look like the following.
+Our first step is to separate privileged and unprivileged code in the codebase of Jinux. For our purpose of demonstrating a syscall handling framework, a minimal codebase may look like the following.
 
 ```text
 .
-├── kxos
+├── jinux
 │   ├── src
 │   │   └── main.rs
 │   └── Cargo.toml
-├── kxos-core
+├── jinux-core
 │   ├── src
 │   │   ├── lib.rs
 │   │   ├── syscall_handler.rs
@@ -162,7 +162,7 @@ Our first step is to separate privileged and unprivileged code in the codebase o
 │   │       ├── vmo.rs
 │   │       └── vmar.rs
 │   └── Cargo.toml
-├── kxos-core-libs
+├── jinux-core-libs
 │   ├── linux-abi-types
 │   │   ├── src
 │   │   │   └── lib.rs
@@ -171,34 +171,34 @@ Our first step is to separate privileged and unprivileged code in the codebase o
 │       ├── src
 │       │   └── lib.rs
 │       └── Cargo.toml
-├── kxos-comps
+├── jinux-comps
 │   └── linux-syscall
 │       ├── src
 │       │   └── lib.rs
 │       └── Cargo.toml
-└── kxos-comp-libs
+└── jinux-comp-libs
     └── linux-abi
         ├── src
         │   └── lib.rs
         └── Cargo.toml 
 ```
 
-The ultimate build target of the codebase is the `kxos` crate, which is an OS kernel that consists of a privileged OS core (crate `kxos-core`) and multiple OS components (the crates under `kxos-comps/`).
+The ultimate build target of the codebase is the `jinux` crate, which is an OS kernel that consists of a privileged OS core (crate `jinux-core`) and multiple OS components (the crates under `jinux-comps/`).
 
-For the sake of privilege separation, only crate `kxos` and `kxos-core` along with the crates under `kxos-core-libs` are allowed to use the `unsafe` keyword. To the contrary, the crates under `kxos-comps/` along with their dependent crates under `kxos-comp-libs/` are not allowed to use `unsafe` directly; they may only borrow the superpower of `unsafe` by using the safe API exposed by `kxos-core` or the crates under `kxos-core-libs`. To summarize, the memory safety of the OS only relies on a small and well-defined TCB that constitutes the `kxos` and `kxos-core` crate plus the crates under `kxos-core-libs/`.
+For the sake of privilege separation, only crate `jinux` and `jinux-core` along with the crates under `jinux-core-libs` are allowed to use the `unsafe` keyword. To the contrary, the crates under `jinux-comps/` along with their dependent crates under `jinux-comp-libs/` are not allowed to use `unsafe` directly; they may only borrow the superpower of `unsafe` by using the safe API exposed by `jinux-core` or the crates under `jinux-core-libs`. To summarize, the memory safety of the OS only relies on a small and well-defined TCB that constitutes the `jinux` and `jinux-core` crate plus the crates under `jinux-core-libs/`.
 
-Under this setting, all implementation of system calls goes to the `linux-syscall` crate. We are about to show that the _safe_ API provided by `kxos-core` is powerful enough to enable the _safe_ implementation of `linux-syscall`.
+Under this setting, all implementation of system calls goes to the `linux-syscall` crate. We are about to show that the _safe_ API provided by `jinux-core` is powerful enough to enable the _safe_ implementation of `linux-syscall`.
 
-## Crate `kxos-core`
+## Crate `jinux-core`
 
-For our purposes here, the two most relevant APIs provided by `kxos-core` is the abstraction for syscall handlers and virtual memory (VM).
+For our purposes here, the two most relevant APIs provided by `jinux-core` is the abstraction for syscall handlers and virtual memory (VM).
 
 ### Syscall handlers
 
 The `SyscallHandler` abstraction enables the OS core to hide the low-level, architectural-dependent aspects of syscall handling workflow (e.g., user-kernel switching and CPU register manipulation) and allow the unprivileged OS components to implement system calls.
 
 ```rust
-// file: kxos-core/src/syscall_handler.rs
+// file: jinux-core/src/syscall_handler.rs
 
 pub trait SyscallHandler {
     fn handle_syscall(&self, ctx: &mut SyscallContext);
@@ -243,8 +243,8 @@ an important concept that we will elaborate on later. Basically, they are capabi
 Here we demonstrate how to leverage the APIs of `ksos-core` to implement system calls with safe Rust code in crate `linux-syscall`.
 
 ```rust
-// file: kxos-comps/linux-syscall/src/lib.rs
-use kxos_core::{SyscallContext, SyscallHandler, Vmar};
+// file: jinux-comps/linux-syscall/src/lib.rs
+use jinux_core::{SyscallContext, SyscallHandler, Vmar};
 use linux_abi::{SyscallNum::*, UserPtr, RawFd, RawTimeVal, RawTimeZone};
 
 pub struct SampleHandler;
@@ -315,7 +315,7 @@ impl SampleHandler {
 This crate defines a marker trait `Pod`, which represents plain-old data.
 
 ```rust
-/// file: kxos-core-libs/pod/src/lib.rs
+/// file: jinux-core-libs/pod/src/lib.rs
 
 /// A marker trait for plain old data (POD).
 ///
@@ -388,7 +388,7 @@ unsafe impl<T: Pod, const N> [T; N] for Pod {}
 ## Crate `linux-abi-type`
 
 ```rust
-// file: kxos-core-libs/linux-abi-types
+// file: jinux-core-libs/linux-abi-types
 use pod::Pod;
 
 pub type RawFd = i32;
@@ -404,7 +404,7 @@ unsafe impl Pod for RawTimeVal {}
 ## Crate `linux-abi`
 
 ```rust
-// file: kxos-comp-libs/linux-abi
+// file: jinux-comp-libs/linux-abi
 pub use linux_abi_types::*;
 
 pub enum SyscallNum {

src/.cargo/config.toml

@@ -1,6 +1,6 @@
 
 [target.'cfg(target_os = "none")']
-runner = "cargo run --package kxos-boot --"
+runner = "cargo run --package jinux-boot --"
 
 [alias]
 kcheck = "check --target x86_64-custom.json -Zbuild-std=core,alloc,compiler_builtins  -Zbuild-std-features=compiler-builtins-mem"

src/Cargo.lock

@@ -34,9 +34,9 @@ checksum = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a"
 
 [[package]]
 name = "bootloader"
-version = "0.10.12"
+version = "0.10.13"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "f2d9b14b92a825ecc3b24e4c163a578af473fbba5f190bfaf48092b29b604504"
+checksum = "24e13520aa8580a2850fc9f5390dc6753f1062fb66f90e5a61bd5c72b55df731"
 
 [[package]]
 name = "bootloader-locator"
@@ -78,22 +78,16 @@ dependencies = [
 ]
 
 [[package]]
-name = "json"
-version = "0.12.4"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "078e285eafdfb6c4b434e0d31e8cfcb5115b651496faca5749b88fafd4f23bfd"
-
-[[package]]
-name = "kxos"
+name = "jinux"
 version = "0.1.0"
 dependencies = [
  "bootloader",
- "kxos-frame",
- "kxos-std",
+ "jinux-frame",
+ "jinux-std",
 ]
 
 [[package]]
-name = "kxos-boot"
+name = "jinux-boot"
 version = "0.1.0"
 dependencies = [
  "anyhow",
@@ -103,7 +97,7 @@ dependencies = [
 ]
 
 [[package]]
-name = "kxos-frame"
+name = "jinux-frame"
 version = "0.1.0"
 dependencies = [
  "bitflags",
@@ -112,6 +106,8 @@ dependencies = [
  "font8x8",
  "lazy_static",
  "linked_list_allocator",
+ "pod",
+ "pod-derive",
  "spin 0.9.4",
  "uart_16550",
  "volatile",
@@ -119,28 +115,20 @@ dependencies = [
 ]
 
 [[package]]
-name = "kxos-frame-pod-derive"
-version = "0.1.0"
-dependencies = [
- "proc-macro2",
- "quote",
- "syn",
-]
-
-[[package]]
-name = "kxos-pci"
+name = "jinux-pci"
 version = "0.1.0"
 dependencies = [
  "bitflags",
- "kxos-frame",
- "kxos-frame-pod-derive",
- "kxos-util",
+ "jinux-frame",
+ "jinux-util",
  "lazy_static",
+ "pod",
+ "pod-derive",
  "spin 0.9.4",
 ]
 
 [[package]]
-name = "kxos-rights-proc"
+name = "jinux-rights-proc"
 version = "0.1.0"
 dependencies = [
  "proc-macro2",
@@ -149,57 +137,53 @@ dependencies = [
 ]
 
 [[package]]
-name = "kxos-std"
+name = "jinux-std"
 version = "0.1.0"
 dependencies = [
  "bitflags",
- "kxos-frame",
- "kxos-frame-pod-derive",
- "kxos-pci",
- "kxos-rights-proc",
- "kxos-typeflags",
- "kxos-typeflags-util",
- "kxos-virtio",
+ "jinux-frame",
+ "jinux-pci",
+ "jinux-rights-proc",
+ "jinux-virtio",
  "lazy_static",
+ "pod",
+ "pod-derive",
  "ringbuffer",
  "spin 0.9.4",
+ "typeflags",
+ "typeflags-util",
  "vte",
  "xmas-elf",
 ]
 
 [[package]]
-name = "kxos-typeflags"
+name = "jinux-util"
 version = "0.1.0"
 dependencies = [
- "itertools",
- "proc-macro2",
- "quote",
- "syn",
+ "jinux-frame",
+ "pod",
+ "pod-derive",
 ]
 
 [[package]]
-name = "kxos-typeflags-util"
-version = "0.1.0"
-
-[[package]]
-name = "kxos-util"
-version = "0.1.0"
-dependencies = [
- "kxos-frame",
-]
-
-[[package]]
-name = "kxos-virtio"
+name = "jinux-virtio"
 version = "0.1.0"
 dependencies = [
  "bitflags",
- "kxos-frame",
- "kxos-frame-pod-derive",
- "kxos-pci",
- "kxos-util",
+ "jinux-frame",
+ "jinux-pci",
+ "jinux-util",
+ "pod",
+ "pod-derive",
  "spin 0.9.4",
 ]
 
+[[package]]
+name = "json"
+version = "0.12.4"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "078e285eafdfb6c4b434e0d31e8cfcb5115b651496faca5749b88fafd4f23bfd"
+
 [[package]]
 name = "lazy_static"
 version = "1.4.0"
@@ -211,9 +195,9 @@ dependencies = [
 
 [[package]]
 name = "libc"
-version = "0.2.132"
+version = "0.2.137"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "8371e4e5341c3a96db127eb2465ac681ced4c433e01dd0e938adbef26ba93ba5"
+checksum = "fc7fcc620a3bff7cdd7a365be3376c97191aeaccc2a603e600951e452615bf89"
 
 [[package]]
 name = "linked_list_allocator"
@@ -235,19 +219,32 @@ dependencies = [
 
 [[package]]
 name = "lock_api"
-version = "0.4.8"
+version = "0.4.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "9f80bf5aacaf25cbfc8210d1cfb718f2bf3b11c4c54e5afe36c236853a8ec390"
+checksum = "435011366fe56583b16cf956f9df0095b405b82d76425bc8981c0e22e60ec4df"
 dependencies = [
  "autocfg",
  "scopeguard",
 ]
 
+[[package]]
+name = "pod"
+version = "0.1.0"
+
+[[package]]
+name = "pod-derive"
+version = "0.1.0"
+dependencies = [
+ "proc-macro2",
+ "quote",
+ "syn",
+]
+
 [[package]]
 name = "proc-macro2"
-version = "1.0.43"
+version = "1.0.47"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "0a2ca2c61bc9f3d74d2886294ab7b9853abd9c1ad903a3ac7815c58989bb7bab"
+checksum = "5ea3d908b0e36316caf9e9e2c4625cdde190a7e6f440d794667ed17a1855e725"
 dependencies = [
  "unicode-ident",
 ]
@@ -321,9 +318,9 @@ dependencies = [
 
 [[package]]
 name = "syn"
-version = "1.0.99"
+version = "1.0.103"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "58dbef6ec655055e20b86b15a8cc6d439cca19b667537ac6a1369572d151ab13"
+checksum = "a864042229133ada95abf3b54fdc62ef5ccabe9515b64717bcb9a1919e59445d"
 dependencies = [
  "proc-macro2",
  "quote",
@@ -332,24 +329,38 @@ dependencies = [
 
 [[package]]
 name = "thiserror"
-version = "1.0.33"
+version = "1.0.37"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "3d0a539a918745651435ac7db7a18761589a94cd7e94cd56999f828bf73c8a57"
+checksum = "10deb33631e3c9018b9baf9dcbbc4f737320d2b576bac10f6aefa048fa407e3e"
 dependencies = [
  "thiserror-impl",
 ]
 
 [[package]]
 name = "thiserror-impl"
-version = "1.0.33"
+version = "1.0.37"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "c251e90f708e16c49a16f4917dc2131e75222b72edfa9cb7f7c58ae56aae0c09"
+checksum = "982d17546b47146b28f7c22e3d08465f6b8903d0ea13c1660d9d84a6e7adcdbb"
 dependencies = [
  "proc-macro2",
  "quote",
  "syn",
 ]
 
+[[package]]
+name = "typeflags"
+version = "0.1.0"
+dependencies = [
+ "itertools",
+ "proc-macro2",
+ "quote",
+ "syn",
+]
+
+[[package]]
+name = "typeflags-util"
+version = "0.1.0"
+
 [[package]]
 name = "uart_16550"
 version = "0.2.18"
@@ -363,9 +374,9 @@ dependencies = [
 
 [[package]]
 name = "unicode-ident"
-version = "1.0.3"
+version = "1.0.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "c4f5b37a154999a8f3f98cc23a628d850e154479cd94decf3414696e12e31aaf"
+checksum = "6ceab39d59e4c9499d4e5a8ee0e2735b891bb7308ac83dfb4e80cad195c9f6f3"
 
 [[package]]
 name = "utf8parse"

src/Cargo.toml

@@ -1,26 +1,27 @@
 [package]
-name = "kxos"
+name = "jinux"
 version = "0.1.0"
 edition = "2021"
 
 [dependencies]
 bootloader = {version="0.10.12"}
-kxos-frame = {path = "kxos-frame"}
-kxos-std = {path = "kxos-std"}
+jinux-frame = {path = "framework/jinux-frame"}
+jinux-std = {path = "services/libs/jinux-std"}
 
 [workspace]
 
 members = [
-    "kxos-frame",
-    "kxos-std",
-    "kxos-boot",
-    "kxos-pci",
-    "kxos-virtio",
-    "kxos-util",
-    "kxos-frame-pod-derive",
-    "kxos-typeflags",
-    "kxos-typeflags-util",
-    "kxos-rights-proc",
+    "jinux-boot",
+    "framework/jinux-frame",
+    "framework/pod",
+    "framework/pod-derive",
+    "services/comps/jinux-pci",
+    "services/comps/jinux-virtio",
+    "services/libs/jinux-std",
+    "services/libs/jinux-rights-proc",
+    "services/libs/typeflags",
+    "services/libs/typeflags-util",
+    "services/libs/jinux-util",
 ]
 
 [package.metadata.bootloader]

src/README.md

@@ -1,27 +1,27 @@
-# KxOS Source Code
+# Jinux Source Code
 
 ## Code organization
 
 The codebase is organized as a number of Rust crates.
 
-* The `kxos` crate assembles all other crates into a runnable OS kernel image.
+* The `jinux` crate assembles all other crates into a runnable OS kernel image.
 This is the only binary crate; all other crates are libraries.
-* The `kxos-frame` crate constitutes the main part of the KxOS framework,
+* The `jinux-frame` crate constitutes the main part of the jinux framework,
 providing a minimal set of _safe_ abstractions that encapsulates _unsafe_ Rust
 code to deal with hardware resources like CPU, memory, and interrupts.
-* The `kxos-frame-*` crates complement `kxos-frame` by providing more _safe_ 
-types, APIs, or abstractions that are useful to specific aspects of the KxOS.
-* The `kxos-std` crate is KxOS's equivalent of Rust's std crate, although 
+* The `jinux-frame-*` crates complement `jinux-frame` by providing more _safe_ 
+types, APIs, or abstractions that are useful to specific aspects of the Jinux.
+* The `jinux-std` crate is Jinux's equivalent of Rust's std crate, although 
 their APIs are quite different. This crate offers an extensive set of 
 high-level safe APIs that are widely used throughout the OS code above the
 framework (i.e., the crates described below).
-* The rest of `kxos-*` crates implement most of the functionalities of KxOS, e.g., 
+* The rest of `jinux-*` crates implement most of the functionalities of Jinux, e.g., 
 Linux syscall dispatching, process management, file systems, network stacks,
 and device drivers.
 
 ## Privilege separation
 
-KxOS is a _framekernel_, separating the entire OS into two halves:
+Jinux is a _framekernel_, separating the entire OS into two halves:
 the _privileged_ half (so-called "frame") and the _unprivileged_ half.
 Only the privileged half is allowed to include any _unsafe_ Rust code. And 
 it is the privileged half's responsibility to encapsulate the _unsafe_ Rust
@@ -30,5 +30,5 @@ with safe Rust in the unprivileged half.
 
 This philosophy of privilege separationn is also reflected in the code organization.
 
-* The privileged half consists of `kxos`, `kxos-frame`, and `kxos-frame-*` crates.
-* The unprivileged half consists of `kxos-std` and the rest `kxos-*` crates.
+* The privileged half consists of `jinux`, `jinux-frame`, and `jinux-frame-*` crates.
+* The unprivileged half consists of `jinux-std` and the rest `jinux-*` crates.

src/apps/signal_c/signal_test.c

@@ -185,7 +185,7 @@ int test_handle_sigfpe() {
     c = div_maybe_zero(a, b);
     fxsave(y);
 
-    // kxos does not save and restore fpregs now, so we emit this check.
+    // jinux does not save and restore fpregs now, so we emit this check.
     // if (memcmp(x, y, 512) != 0) {
     //     THROW_ERROR("floating point registers are modified");
     // }

src/framework/jinux-frame/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "kxos-frame"
+name = "jinux-frame"
 version = "0.1.0"
 edition = "2021"
 
@@ -15,6 +15,8 @@ linked_list_allocator = "0.9.0"
 bootloader = {version="0.10.12"}
 font8x8 = { version = "0.2.5", default-features = false, features = ["unicode"]}
 uart_16550 = "0.2.0"
+pod = {path = "../pod"}
+pod-derive = {path = "../pod-derive"}
 
 [dependencies.lazy_static]
 version = "1.0"

src/framework/jinux-frame/src/cpu.rs

@@ -6,7 +6,7 @@ use core::mem::MaybeUninit;
 
 use crate::debug;
 use crate::trap::{CalleeRegs, CallerRegs, SyscallFrame, TrapFrame};
-use crate::vm::Pod;
+use pod::Pod;
 
 /// Defines a CPU-local variable.
 #[macro_export]

src/framework/jinux-frame/src/lib.rs

@@ -1,4 +1,4 @@
-//! The framework part of KxOS.
+//! The framework part of Jinux.
 #![no_std]
 #![allow(dead_code)]
 #![allow(unused_variables)]
@@ -45,7 +45,6 @@ pub use mm::address::{align_down, align_up, is_aligned, virt_to_phys};
 pub use trap::{allocate_irq, IrqAllocateHandle, TrapFrame};
 use trap::{IrqCallbackHandle, IrqLine};
 pub use util::AlignExt;
-pub use vm::Pod;
 use x86_64_util::enable_common_cpu_features;
 
 static mut IRQ_CALLBACK_LIST: Vec<IrqCallbackHandle> = Vec::new();

src/framework/jinux-frame/src/trap/handler.rs

@@ -26,7 +26,7 @@ pub(crate) extern "C" fn trap_handler(f: &mut TrapFrame) {
         current.inner_exclusive_access().is_from_trap = true;
         *current.trap_frame() = *SWITCH_TO_USER_SPACE_TASK.trap_frame();
         if is_cpu_fault(current.trap_frame()) {
-            // if is cpu fault, we will pass control to trap handler in kxos std
+            // if is cpu fault, we will pass control to trap handler in jinux std
             unsafe {
                 context_switch(
                     get_idle_task_cx_ptr() as *mut TaskContext,
@@ -68,7 +68,7 @@ fn is_from_kernel(cs: u64) -> bool {
 /// Aborts: Some severe unrecoverable error.
 
 /// This function will determine a trap is a CPU faults.
-/// We will pass control to kxos-std if the trap is **faults**.
+/// We will pass control to jinux-std if the trap is **faults**.
 pub fn is_cpu_fault(trap_frame: &TrapFrame) -> bool {
     match trap_frame.id {
         DIVIDE_BY_ZERO

src/framework/jinux-frame/src/trap/irq.rs

@@ -28,7 +28,7 @@ pub(crate) fn allocate_target_irq(target_irq: u8) -> Result<IrqAllocateHandle> {
     }
 }
 
-/// The handle to a allocate irq number between [32,256), used in std and other parts in kxos
+/// The handle to a allocate irq number between [32,256), used in std and other parts in jinux
 ///
 /// When the handle is dropped, all the callback in this will be unregistered automatically.
 #[derive(Debug)]

src/framework/jinux-frame/src/user.rs

@@ -69,7 +69,7 @@ impl UserSpace {
 /// Here is a sample code on how to use `UserMode`.
 ///  
 /// ```no_run
-/// use kxos_frame::task::Task;
+/// use jinux_frame::task::Task;
 ///
 /// let current = Task::current();
 /// let user_space = current.user_space()

src/framework/jinux-frame/src/vm/frame.rs

@@ -1,6 +1,7 @@
 use core::iter::Iterator;
 
-use crate::{config::PAGE_SIZE, mm::address::PhysAddr, prelude::*, Error, Pod};
+use crate::{config::PAGE_SIZE, mm::address::PhysAddr, prelude::*, Error};
+use pod::Pod;
 
 use super::VmIo;
 

src/framework/jinux-frame/src/vm/io.rs

@@ -1,5 +1,5 @@
 use crate::prelude::*;
-use crate::vm::Pod;
+use pod::Pod;
 
 /// A trait that enables reading/writing data from/to a VM object,
 /// e.g., `VmSpace`, `VmFrameVec`, and `VmFrame`.

src/framework/jinux-frame/src/vm/mod.rs

@@ -8,10 +8,9 @@ pub type Paddr = usize;
 
 mod frame;
 mod io;
-mod pod;
+mod offset;
 mod space;
 
 pub use self::frame::{VmAllocOptions, VmFrame, VmFrameVec, VmFrameVecIter};
 pub use self::io::VmIo;
-pub use self::pod::Pod;
 pub use self::space::{VmMapOptions, VmPerm, VmSpace};

src/framework/jinux-frame/src/vm/offset.rs

@@ -0,0 +1,35 @@
+/// Get the offset of a field within a type as a pointer.
+///
+/// ```rust
+/// #[repr(C)]
+/// pub struct Foo {
+///     first: u8,
+///     second: u32,
+/// }
+///
+/// assert!(offset_of(Foo, first) == (0 as *const u8));
+/// assert!(offset_of(Foo, second) == (4 as *const u32));
+/// ```
+#[macro_export]
+macro_rules! offset_of {
+    ($container:ty, $($field:tt)+) => ({
+        // SAFETY. It is ok to have this uninitialized value because
+        // 1) Its memory won't be acccessed;
+        // 2) It will be forgoten rather than being dropped;
+        // 3) Before it gets forgten, the code won't return prematurely or panic.
+        let tmp: $container = unsafe { core::mem::MaybeUninit::uninit().assume_init() };
+
+        let container_addr = &tmp as *const _;
+        let field_addr =  &tmp.$($field)* as *const _;
+
+        ::core::mem::forget(tmp);
+
+        let field_offset = (field_addr as usize - container_addr as usize) as *const _;
+
+        // Let Rust compiler infer our intended pointer type of field_offset
+        // by comparing it with another pointer.
+        let _: bool = field_offset == field_addr;
+
+        field_offset
+    });
+}

src/framework/pod-derive/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "kxos-frame-pod-derive"
+name = "pod-derive"
 version = "0.1.0"
 edition = "2021"
 

src/framework/pod-derive/src/lib.rs

@@ -1,5 +1,5 @@
-//! This crate is used to provide a procedural macro to derive Pod trait defined in kxos_frame.
-//! When use this crate, kxos-frame should also be added as a dependency.
+//! This crate is used to provide a procedural macro to derive Pod trait defined in framework/pod.
+//! When use this crate, framework/pod should also be added as a dependency.
 //! This macro should only be used outside
 //! When derive Pod trait, we will do a check whether the derive is safe since Pod trait is an unsafe trait.
 //! For struct, we will check that the struct has valid repr (e.g,. repr(C), repr(u8)), and each field is Pod type.
@@ -53,7 +53,7 @@ fn impl_pod_for_struct(
         .map(|field| {
             let field_ty = field.ty;
             quote! {
-                #field_ty: ::kxos_frame::Pod
+                #field_ty: ::pod::Pod
             }
         })
         .collect::<Vec<_>>();
@@ -62,12 +62,12 @@ fn impl_pod_for_struct(
     if where_clause.is_none() {
         quote! {
             #[automatically_derived]
-            unsafe impl #impl_generics ::kxos_frame::Pod #type_generics for #ident where #(#pod_where_predicates),* {}
+            unsafe impl #impl_generics ::pod::Pod #type_generics for #ident where #(#pod_where_predicates),* {}
         }
     } else {
         quote! {
             #[automatically_derived]
-            unsafe impl #impl_generics ::kxos_frame::Pod #type_generics for #ident #where_clause, #(#pod_where_predicates),* {}
+            unsafe impl #impl_generics ::pod::Pod #type_generics for #ident #where_clause, #(#pod_where_predicates),* {}
         }
     }
 }
@@ -88,7 +88,7 @@ fn impl_pod_for_enum_or_union(
     let (impl_generics, type_generics, where_clause) = generics.split_for_impl();
     quote! {
         #[automatically_derived]
-        unsafe impl #impl_generics ::kxos_frame::Pod #type_generics for #ident #where_clause {}
+        unsafe impl #impl_generics ::pod::Pod #type_generics for #ident #where_clause {}
     }
 }
 

src/framework/pod/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "kxos-typeflags-util"
+name = "pod"
 version = "0.1.0"
 edition = "2021"
 

src/framework/pod/src/lib.rs

@@ -1,3 +1,5 @@
+#![no_std]
+
 use core::{fmt::Debug, mem::MaybeUninit};
 
 /// A marker trait for plain old data (POD).
@@ -57,43 +59,7 @@ macro_rules! impl_pod_for {
         $(unsafe impl Pod for $pod_ty {})*
     };
 }
-
+// impl Pod for primitive types
 impl_pod_for!(u8, u16, u32, u64, i8, i16, i32, i64, isize, usize);
-
+// impl Pod for array
 unsafe impl<T: Pod, const N: usize> Pod for [T; N] {}
-
-/// Get the offset of a field within a type as a pointer.
-///
-/// ```rust
-/// #[repr(C)]
-/// pub struct Foo {
-///     first: u8,
-///     second: u32,
-/// }
-///
-/// assert!(offset_of(Foo, first) == (0 as *const u8));
-/// assert!(offset_of(Foo, second) == (4 as *const u32));
-/// ```
-#[macro_export]
-macro_rules! offset_of {
-    ($container:ty, $($field:tt)+) => ({
-        // SAFETY. It is ok to have this uninitialized value because
-        // 1) Its memory won't be acccessed;
-        // 2) It will be forgoten rather than being dropped;
-        // 3) Before it gets forgten, the code won't return prematurely or panic.
-        let tmp: $container = unsafe { core::mem::MaybeUninit::uninit().assume_init() };
-
-        let container_addr = &tmp as *const _;
-        let field_addr =  &tmp.$($field)* as *const _;
-
-        ::core::mem::forget(tmp);
-
-        let field_offset = (field_addr as usize - container_addr as usize) as *const _;
-
-        // Let Rust compiler infer our intended pointer type of field_offset
-        // by comparing it with another pointer.
-        let _: bool = field_offset == field_addr;
-
-        field_offset
-    });
-}

src/jinux-boot/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "kxos-boot"
+name = "jinux-boot"
 version = "0.1.0"
 edition = "2021"
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

src/kxos-std/src/user_apps.rs

@@ -1,122 +0,0 @@
-use crate::prelude::*;
-
-pub struct UserApp {
-    pub app_name: CString,
-    pub app_content: &'static [u8],
-    pub argv: Vec<CString>,
-    pub envp: Vec<CString>,
-}
-
-impl UserApp {
-    pub fn new(app_name: &str, app_content: &'static [u8]) -> Self {
-        let app_name = CString::new(app_name).unwrap();
-        UserApp {
-            app_name,
-            app_content,
-            argv: Vec::new(),
-            envp: Vec::new(),
-        }
-    }
-
-    pub fn set_argv(&mut self, argv: Vec<CString>) {
-        self.argv = argv;
-    }
-
-    pub fn set_envp(&mut self, envp: Vec<CString>) {
-        self.envp = envp;
-    }
-}
-
-pub fn get_all_apps() -> Vec<UserApp> {
-    let mut res = Vec::with_capacity(16);
-
-    // Most simple hello world, written in assembly
-    let asm_hello_world = UserApp::new("hello_world", read_hello_world_content());
-    res.push(asm_hello_world);
-
-    // Hello world, written in C language.
-    // Since glibc requires the app name starts with "/", and we don't have filesystem now.
-    // So we manually add a leading "/" for app written in C language.
-    let hello_c = UserApp::new("/hello_c", read_hello_c_content());
-    res.push(hello_c);
-
-    // Fork process, written in assembly
-    let asm_fork = UserApp::new("fork", read_fork_content());
-    res.push(asm_fork);
-
-    // Execve, written in C language.
-    let execve_c = UserApp::new("/execve", read_execve_content());
-    res.push(execve_c);
-
-    // Fork new process, written in C language. (Fork in glibc uses syscall clone actually)
-    let fork_c = UserApp::new("/fork", read_fork_c_content());
-    res.push(fork_c);
-
-    // signal test
-    let signal_test = UserApp::new("/signal_test", read_signal_test_content());
-    res.push(signal_test);
-
-    // busybox
-    let mut busybox = UserApp::new("/busybox", read_busybox_content());
-    // -l option means the busybox is running as logging shell
-    let argv = ["/busybox", "sh", "-l"];
-    // let envp = ["SHELL=/bin/bash", "COLORTERM=truecolor", "TERM_PROGRAM_VERSION=1.73.0", "LC_ADDRESS=zh_CN.UTF-8", "LC_NAME=zh_CN.UTF-8", "LC_MONETARY=zh_CN.UTF-8", "PWD=/", "LOGNAME=root", "XDG_SESSION_TYPE=tty", "VSCODE_GIT_ASKPASS_NODE=/home/jiangjf/.vscode-server/bin/8fa188b2b301d36553cbc9ce1b0a146ccb93351f/node", "MOTD_SHOWN=pam", "HOME=/home/jiangjf", "LC_PAPER=zh_CN.UTF-8", "LANG=en_US.UTF-8", "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35", "GIT_ASKPASS=/home/jiangjf/.vscode-server/bin/8fa188b2b301d36553cbc9ce1b0a146ccb93351f/extensions/git/dist/askpass.sh", "SSH_CONNECTION=30.177.3.156 54687 30.77.178.76 22", "VSCODE_GIT_ASKPASS_EXTRA_ARGS=", "LESSCLOSE=/usr/bin/lesspipe %s %s", "XDG_SESSION_CLASS=user", "TERM=xterm-256color", "LC_IDENTIFICATION=zh_CN.UTF-8", "LESSOPEN=| /usr/bin/lesspipe %s", "USER=jiangjf", "VSCODE_GIT_IPC_HANDLE=/run/user/1015/vscode-git-623b69fb06.sock", "SHLVL=2", "LC_TELEPHONE=zh_CN.UTF-8", "LC_MEASUREMENT=zh_CN.UTF-8", "XDG_SESSION_ID=8884", "XDG_RUNTIME_DIR=/run/user/1015", "SSH_CLIENT=30.177.3.156 54687 22", "LC_TIME=zh_CN.UTF-8", "VSCODE_GIT_ASKPASS_MAIN=/home/jiangjf/.vscode-server/bin/8fa188b2b301d36553cbc9ce1b0a146ccb93351f/extensions/git/dist/askpass-main.js", "XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop", "BROWSER=/home/jiangjf/.vscode-server/bin/8fa188b2b301d36553cbc9ce1b0a146ccb93351f/bin/helpers/browser.sh", "PATH=/home/jiangjf/.vscode-server/bin/8fa188b2b301d36553cbc9ce1b0a146ccb93351f/bin/remote-cli:/home/jiangjf/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin", "DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1015/bus", "LC_NUMERIC=zh_CN.UTF-8", "TERM_PROGRAM=vscode", "VSCODE_IPC_HOOK_CLI=/run/user/1015/vscode-ipc-ed06ed64-441d-4b59-a8fe-90ce2cf29a8a.sock", "OLDPWD=/"];
-    let envp = [
-        "SHELL=/bin/sh",
-        "PWD=/",
-        "LOGNAME=root",
-        "HOME=/",
-        "USER=root",
-        "PATH=",
-        "OLDPWD=/",
-    ];
-
-    let argv = to_vec_cstring(&argv).unwrap();
-    let envp = to_vec_cstring(&envp).unwrap();
-    busybox.set_argv(argv);
-    busybox.set_envp(envp);
-    res.push(busybox);
-
-    res
-}
-
-fn read_hello_world_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/hello_world/hello_world")
-}
-
-fn read_hello_c_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/hello_c/hello")
-}
-
-fn read_fork_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/fork/fork")
-}
-
-fn read_execve_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/execve/execve")
-}
-
-pub fn read_execve_hello_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/execve/hello")
-}
-
-fn read_fork_c_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/fork_c/fork")
-}
-
-fn read_signal_test_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/signal_c/signal_test")
-}
-
-fn read_busybox_content() -> &'static [u8] {
-    include_bytes!("../../kxos-user/busybox/busybox")
-}
-
-fn to_vec_cstring(raw_strs: &[&str]) -> Result<Vec<CString>> {
-    let mut res = Vec::new();
-    for raw_str in raw_strs {
-        let cstring = CString::new(*raw_str)?;
-        res.push(cstring);
-    }
-    Ok(res)
-}

src/kxos-virtio/Cargo.toml

@@ -1,18 +0,0 @@
-[package]
-name = "kxos-virtio"
-version = "0.1.0"
-edition = "2021"
-
-# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
-
-[dependencies]
-bitflags = "1.3"
-spin = "0.9.4"
-kxos-frame = {path = "../kxos-frame"}
-kxos-pci = {path="../kxos-pci"}
-kxos-util = {path="../kxos-util"}
-kxos-frame-pod-derive = {path = "../kxos-frame-pod-derive"}
-
-
-[features]
-

src/services/comps/jinux-pci/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "kxos-pci"
+name = "jinux-pci"
 version = "0.1.0"
 edition = "2021"
 
@@ -8,9 +8,10 @@ edition = "2021"
 [dependencies]
 bitflags = "1.3"
 spin = "0.9.4"
-kxos-frame = {path = "../kxos-frame"}
-kxos-util = {path="../kxos-util"}
-kxos-frame-pod-derive = {path = "../kxos-frame-pod-derive"}
+jinux-frame = {path = "../../../framework/jinux-frame"}
+jinux-util = {path="../../libs/jinux-util"}
+pod = {path = "../../../framework/pod"}
+pod-derive = {path = "../../../framework/pod-derive"}
 
 [dependencies.lazy_static]
 version = "1.0"