blog_os
blog_os copied to clipboard
phil-opp
Open source composition of Edition 3
Progress on the third edition is likely to go much faster if everyone is able to contribute. Although I’ve heard that work on the third edition is indeed in progress, there’s so far nothing visible (yet) — a “work-in-progress” branch of the repository where pre-release contribution to the third edition would be possible would at least get more contributors on board, and the more possible contributors, the faster the development of the third edition of the book would go.
Thanks for the suggestion and for offering to help!
Right now, the main blocker is that I'm still not satisfied with the new build system. In its current state, we wouldn't be able to use the default cargo build/cargo test/cargo run commands anymore and instead use alias commands (e.g. cargo kbuild) to pass the --target and -Zbuild-std arguments. Another drawback is that we would not be able to use the upcoming artifact dependencies feature of cargo.
The best solution for this is to support more .cargo/config settings in Cargo.toml files too, as I proposed on the internals forum. In order to support cargo build etc. with our new build system, we would need to set the following options in our Cargo.toml:
- [x]
build.target- Landed in https://github.com/rust-lang/cargo/pull/9030
- [ ] needs to be fixed: https://github.com/rust-lang/cargo/issues/9451
- [ ]
unstable.build-std - [ ]
unstable.build-std-features - [ ]
target.runner
I know that implementing these in cargo isn't an easy task, but it would help very much in bringing the third edition forward.
Submitted rust-lang/cargo#10084 as a fix for the showstopper that you mention — rearranges some code around so that the -Zbuild-std check waits until after generate_targets() is already run. Although rustfmt fails on it, builds on all platforms are successful. Hopefully this solves the problem.
I would make the point that target.runner isn’t as critical as build-std in Cargo.toml because it can already be set in .vscode/settings.json which allows you to just click the “Run” button from VS Code and open it in QEMU that way. That is, of course, after installing the Rust plugin for VS Code and going on to rustup component add rust-analyzer-preview as the backend.
Posted a video to my YouTube channel explaining how to get the VS Code option up and running as an alternative just in case the team decides not to move -Zbuild-std into Cargo.toml as Alex Crichton’s skepticism might indicate.
Alright, since I kind of figured out how to design a logger on my own without the need for Edition 3-Post-3, I've decided to publish my own logger as a standalone crate for other kernels to use in the meantime. Should help speed up Post 3 by a lot.
yo was wondering how long we got till the publishing of edition 3?
There is an edition-3 repository branch but it hasn’t been updated since January 27 (and I have submitted a few pull requests to that branch myself that have yet to be considered for merging).
@phil-opp is still working on a redesign of the bootloader crate: https://github.com/rust-osdev/bootloader/pull/232 This redesign is blocking the 3rd edition.
@phil-opp is still working on a redesign of the bootloader crate: https://github.com/rust-osdev/bootloader/pull/232 This redesign is blocking the 3rd edition.
So that new version of the bootloader has been released; now what? Still no commits to the edition-3 branch in 11 months.
Now that the new bootloader version is ready, I can finally start to write the new posts. I plan to continue my work on the edition-3 branch and I'll comment here once I have some drafts ready. Then I would appreciate some testing and proofreading!
Note that I'm only working on this project in my spare time, so I can't give you a time estimate.
Hello @phil-opp, in the first post on the section Disabling the standard library, there is an incoherent text: and the --edition 2018 flag specifies that we want to use the [2021 edition](https://doc.rust-lang.org/nightly/edition-guide/rust-2021/index.html) of Rust for our crate..
I think that you should change --edition 2018 to --edition 2021.
Post 2 still uses bootloader 0.10 — so the first thing that needs to happen is updating that post to use 0.11 instead. With an already existing migration guide, shouldn't be too difficult, and I'll definitely be glad to help with any drafts of the updated Post 2 here.
Hello! By when can we expect the post 3 for edition 3? Since it looks like there is no more a blocker of the bootloader crate👀
Hello! By when can we expect the post 3 for edition 3? Since it looks like there is no more a blocker of the bootloader crate👀
Post 2 has to be rewritten first because bootloader 0.11 introduces some breaking changes and it was written for 0.10 originally. Biggest change is configuration, which in 0.11 is now in the kernel's source code itself instead of Cargo.toml — see lines 94-113 of my kernel's main.rs file for an example. Another big change in 0.11 is the entry_point! macro, which you now pass a reference to that very configuration structure as an argument to.
Also, you can now choose which firmware type (BIOS, UEFI, or both) to support instead of needing to always support everything. I've got mine in UEFI-only mode (similar to systemd-boot) since it's been more than 10 years since all systems sold on store shelves began shipping with UEFI out of the box.
As for supporting screen output, I've got a crate for that so it shouldn't be difficult either.
Not there yet of course but when @phil-opp gets to the embedded_graphics post (last in the series) I have a (warning: untested) reference implementation that might be worth looking at.
Another important change worth making would be to this post: document how to depend on bootloader-x86_64-common as a way to speed up custom UEFI loader creation
Hello! By when can we expect the post 3 for edition 3? Since it looks like there is no more a blocker of the bootloader crate👀
Update: it's now possible to depend on the logger provided by bootloader-x86_64-common for framebuffer logging — even easier approach than the one I had earlier
Using pull request #1187 to fix edition-3-post-2. Should make it much easier.
@phil-opp I write a writer that use bootloader 0.11 and pixel-based framebuffer (noto_sans_mono_bitmap) based on the code inside the bootloader crate. I can help with the code of post-03 if you want
Merging rust-osdev/bootloader#360 might be an important step here given that it fixes what could become a potential showstopper if left alone
Finally figured out why #1223 was failing the Zola integration; seems the "more" and "TOC" comments are critical for the build process in that case. Completely green on the CI now, so should be ready to merge.
Question about the embedded_graphics crate in edition 3 post 3: When implementing Display, the rust compiler throws a hell of a lot of errors (see log.txt). What version is used in that post? Files: log.txt cargotomlkernel.txt cargotomlmain.txt code.txt
@Abelkrijgtalles That post is still work-in-progress and still contains some code examples that I just wrote down without testing. In your case, the issue seems to be that the struct is named FrameBuffer instead of Framebuffer. You can also check out the post-3.3 branch, which contains the code for this post.