Tracking issue: refactor RROS kernel code

[shannmu]

Tracking issue

• The real-time API identification. (Non-realtime/realtime API refactor #52)
• Code Detail Design (Tracking issue: Refactor code detail design #53)

Additional Information

• After refactoring, optimize the real-time performance of RROS based on performance measurement results(Tracking issue: Build a performance test-suite for various real-time operating systems #49)

[shannmu]

Refactor the current code, which is a breaking change that we will not implement immediately. This thread is for discussing and documenting the issues encountered during the current project development, including unreasonable code design, unsafe code implementations, missing infrastructure, and hacky code that had to be used to push the project forward, etc. We will also discuss how to resolve these issues to make it easier for contributors to contribute to the community and benefit from it.

For any unreasonable parts of the current code, or areas you would like to improve, feel free to give us your feedback.

[Richardhongyu]

Currently, RROS relies on dynamic detection to warn when calling a non-realtime API in the out-of-band code path. This can not cover all the cases.

One possible solution is to utilize the Rust-type system to prevent calling non-realtime API in the real-time code path. This is also beneficial for recovering the R kernel when Linux breaks due to BUGs/wild pointers.

[shannmu]

I am considering whether we need to introduce Cargo. Currently, we are facing several issues:

• Introducing Cargo into the project requires additional work, mainly some modifications to the compilation process.
• Introducing Cargo would bring about the issue of kernel code referencing external code, which might be unacceptable to the upstream community.

The benefits of introducing Cargo are also obvious:

• A richer ecosystem of no_std crates.
• Cargo makes project management simpler.
• It allows the no_std components implemented by RROS to provide crates to external users as one of the targets, making the code more usable.

[shannmu]

I think we need a stronger lint check to standardize the community's coding style, which will also make our code more rusty.

[shannmu]

I think the detailed code refactoring is actually more important than the overall design. To keep this thread from getting too messy, I’m going to split the code detail refactoring into a separate issue. See #53

[Richardhongyu]

I am considering whether we need to introduce Cargo. Currently, we are facing several issues:

As a kernel project relying on Linux, we need to sync with the upstream. Whether to utilize Cargo is up to the choice of RFL.

• A richer ecosystem of no_std crates.

Using Cargo can bring more crates. But importing crates can be achieved with Cargo. You can check the following:

• (Third-party crates support: proc-macro2, quote, syn, serde and serde_derive Rust-for-Linux/linux#1007)
• A discussion on zulip about adding oot modules.
• Another discussion about whether to import Cargo.
• The statement on RFL website

• Cargo makes project management simpler.

Linux has its build toolchain. Using Cargo may conflict with the previous.

IMO, we could use Cargo for importing crates but not for building our system. When to enable Cargo formally depends on the RFL. But we could construct a no_std development environment based on the Cargo experimentally to explore.

[ruiqurm]

I am considering whether we need to introduce Cargo. Currently, we are facing several issues:

As a Linux kernel project, we need to sync with the upstream. Whether to utilize Cargo is up to the choice of RFL.

• A richer ecosystem of no_std crates.

Using Cargo can bring more crates. But importing crates can be achieved with Cargo. You can check the following:

• (Third-party crates support: proc-macro2, quote, syn, serde and serde_derive Rust-for-Linux/linux#1007)
• A discussion on zulip about adding oot modules.
• Another discussion about whether to import Cargo.
• The statement on RFL website

• Cargo makes project management simpler.

Linux has its build toolchain. Using Cargo may conflict with the previous.

IMO, we could use Cargo for importing crates but not for building our system. When to enable Cargo formally depends on the RFL. But we could construct a no_std development environment based on the Cargo experimentally.

Using cargo as built tools:
Pros:

• Rich ecosystem
• We can run an independent OS without Linux in some days.

Using Kbuild:
Pros:

• integrate with Linux origin code perfectly.
• It seems that RFL maintainers do not want to introduce Cargo. Using Kbuild can synchronize with them more easily.

And there is another issue we need to consider. To what extent can the no_std library be adapted for use? I noticed some Rust OS like Redox did not use many dependencies. So we may not get a lot of benefit from the no_std ecosystem?

[Richardhongyu]

Using cargo as built tools: Pros:

• Rich ecosystem

OSDK is organized with Cargo. If we could utilize Rust drivers from OSDK, we could import Cargo. We need to investigate whether this is possible.

• We can run an independent OS without Linux in some days.

If there exists a powerful open-source GPOS being widely used in smart controlling tasks and we decide to support it, Cargo is a good choice. But for the foreseeable days, RROS is still bound to Linux.

Using Kbuild: Pros:

• integrate with Linux origin code perfectly.
• It seems that RFL maintainers do not want to introduce Cargo. Using Kbuild can synchronize with them more easily.

And there is another issue we need to consider. To what extent can the no_std library be adapted for use? I noticed some Rust OS like Redox did not use many dependencies. So we may not get a lot of benefit from the no_std ecosystem?

I think the main benefit is to re-use drivers like virtio and some language features that are not yet merged with Rustc but exist as a library.