In order to build an operating system using the stable channel rust, what problems need to be solved?

[bytesnail]

All the operating system articles about rust you have seen so far are compiled using nightly channel rust.

This works very well at present, and the articles you write are also very interesting and easy to understand. This has provided us with a lot of help in learning about operating system knowledge. I am very grateful for this.

But building a new operating system with the stable channel rust sounds more interesting and practical. Such a new operating system will also make it easier for ordinary users (non-developers) to accept and try, after all, nightly always has a latent meaning of instability.

So, based on your knowledge and information from the community, what other issues need to be resolved in order to use the stable channel rust to build a new operating system? A to-do list suggestion might be a good idea, thank you very much!

[bjorn3]

A probably incomplete list of noghtly only features currently being used:

• Inline asm (Inline assembly rust-lang/rfcs#2850)
• Custom target specifications
• #![feature(custom_test_frameworks)]
• extern "x86-interrupt" fn
• #![feature(alloc_error_handler)]

[AntoineSebert]

In my lib.rs file, I also have the following:

• #![feature(const_fn)]
• #![feature(core_intrinsics)]
• #![feature(custom_test_frameworks)]
• #![feature(trait_alias)]
• #![feature(alloc_layout_extra)]
• #![feature(const_in_array_repeat_expressions)]

But since I tried to extend the OS's features a bit, a couple might not be part of the original blog OS.
That seems quite a lot to be honest, I wouldn't be surprised if all those features stay on the nightly channel for a few years (tho I'm sure workarounds do exist sometimes).

[phil-opp]

Many of these features could be replaced by some stable features, but it would be cumbersome. For example, inline assembly can be replaced by using an external assembler, but this adds another compilation dependency and probably results in slower code (since the compile can't optimize external assembly).

The two blockers (i.e. features that are strictly necessary) of the mentioned features are in my opinion:

• Custom target specifications: While stable rustc can compile for a custom target in theory, the core library is not available for the custom target. Since core uses unstable features itself, compiling it is only possible with a nightly compiler. (You can set the RUSTC_BOOTSTRAP environment variable to bypass this, but this is stricly discouraged because that variable should only be used for building Rust itself.) See https://github.com/rust-lang/wg-cargo-std-aware/ for ongoing work to fix this.
• alloc_error_handler: There is no way around this feature if you want to use the alloc crate. See Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) rust-lang/rust#51540 for more info.