Some questions/comments regarding edition 3

[BSFishy]

I'm working through edition 2 right now, and I am very pleased with how thorough and complete each section is so far. Everything feels quite simple and easy to use, yet extendable when I eventually will need to extend it. Looking through some of the issues, discussions, and projects here, I can see edition 3 is just around the corner, so I have a few questions and comments regarding it.

1. In edition 2, it gives a lot of information about the things that we use (for example, it quite thoroughly explains pic), mentions a bit of history about it usually, and briefly mentions alternatives (e.g. apic rather than pic). I know it might be a bit more work, but I personally would greatly appreciate it if that sort of information could be expanded on. For example, how do modern operating systems handle it? Do they support pic for legacy systems or have they moved to only do apic? What are some resources I could use if I wanted to support apic down the line? I think knowing how modern kernels do things, like Windows NT or Linux, could help a lot in structuring things and knowing what I should focus on when I finish the blog series and start on my own.
2. I'm curious about the build integration with the bootloader when just using the bootloader crate. With edition 2, I'm very pleased with it because I can easily run all of the regular cargo commands like cargo build, cargo test, and cargo run, while still using all of the cargo related features, like specifying feature flags or specifying release mode. Will the build process in edition 3 support all of those sorts of features too? I've briefly looked through the bootloader crate, and it seems to be a bit different from using it along with bootimage.
3. One of the big things that I notice about the series is that it has a strong focus on x86_64 systems. I'm not saying that it's a bad thing because it is pretty much the biggest architecture to target, but I think it would be nice to have somewhat of a starting point for adding support for other architectures in the future. For example, if I wanted my kernel to be able to run on ARM systems, I would need to change out a whole bunch of things to be able to support it. I know it would add complexity to something that is meant to be a simple and easy to follow tutorial, but I think having a section somewhere for more advanced users giving a bit of a starting point or at least explaining how one might go about this would be quite nice.

Needless to say, though, I absolutely love the series! Keep up the great work!

[phil-opp]

Thanks a lot for your thoughts!

Regarding PIC vs APIC: Only the APIC is supported in combination with UEFI, so my plan for the third edition is to use the APIC exclusively. This is also what modern OSs are doing, at least on reasonably modern hardware. I fully agree with your general point that background information and alternatives are very useful!

The build system is actually the biggest blocker for the third edition right now. My idea was to remove the dependency on the bootimage tool and instead let users create the builder crate themselves. This way, it becomes more clear how the build process works and the lock-in is reduced, i.e. it becomes much easier to use some custom configuration (e.g. use a different VM other than QEMU) or even switch to a different bootloader.

The disadvantage of the new build system is that it doesn't work with .cargo/config files. The problem is that they apply to all cargo invocations, including the cargo run of our local builder tool. Thus, it is not possible to set a default target or -Zbuild-std in a .cargo/config file, which requires manual arguments instead, e.g. cargo build --target ... -Zbuild-std=core -Zbuild-std-features .... We can work around that by creating custom aliases such as cargo kbuild, but it's not as nice as being able to just do a norma cargo build.

To solve this, I was submitting a lot of proposals to cargo itself. The most promising is https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336. A small part of it was already implemented in rust-lang/cargo#9030, but it still has some problems for our use case. Unfortunately, I didn't have much time to look into this over the past months. The ultimate goal is to make all the keys that we're currently using in our .cargo/config.toml also available as package-specific keys in the Cargo.toml. Then we could use the standard cargo build, cargo run, etc. commands with the new build system of the third edition too.

Not directly related, but there are other cargo proposals that would be interesting for our new use case, for example, rust-lang/rfcs#3168.

Regarding ARM support: I agree that it would be nice to have some info about porting the system to e.g. ARM at some point. I think the best way to do this would be a separate set of posts that focus on ARM specifically. They probably wouldn't be as detailed as the x86_64 posts, but at least providing some starting points and tips for the code structuring of architecture-specific components would be useful.

[BSFishy]

This all sounds awesome! I think it's really cool that a hobby blog project is pushing new features into Rust and Cargo that anyone can use. I'm super excited and cannot wait until edition 3 comes out.

Regarding ARM support: I agree that it would be nice to have some info about porting the system to e.g. ARM at some point. I think the best way to do this would be a separate set of posts that focus on ARM specifically. They probably wouldn't be as detailed as the x86_64 posts, but at least providing some starting points and tips for the code structuring of architecture-specific components would be useful.

Regarding this, I actually stumbled upon the cfg-if crate yesterday (which fully works in the second edition and I'm currently using it in my project to distinguish feature flags for i.e. different heap allocators). It allows you to use different code depending on cfg() attributes and creates all the necessary configuration to ensure only one is active at a time (i.e. using cfg(all(x, not(any(y, z))))). That could also be accompanied with a compile_error macro in the else block to ensure that one of the cases is applied.

I'm currently working on getting my project ready to upload to Github, but when I get it on here, I'll add a link to an example of how I'm using it. I think this pattern is very applicable to not only switching between the target architecture, but many things, such as feature flags.

Edit: Here is how I have it set up in my project