To explain this further: unresolved import compiler errors are currently thrown when a kernel tries to use bootloader::binary::logger because binary only works when features = ["binary"] is added to Cargo.toml — ah, but simply making that change to its own Cargo.toml is not something a kernel can do without causing the bootloader to panic because it's hardcoded to require the bootloader's built-in custom targets. Hence why I proposed this PR which does 5 things:

1. Move the crates that the Logger depends on (conquer_once, noto_sans_mono_bitmap, spinning_top and of course log) out of binary and into default in the bootloader's Cargo.toml
2. Move src/binary/logger.rs up one level — to the crate root
3. Move pub mod logger from src/binary/mod.rs to the crate root's lib.rs
4. Add a pub use crate::logger line to src/binary/mod.rs for backward compatibility
5. (By accident) duplicate the changes that were originally supposed to go into maybe_uninit_extra is no longer feature-gated in Rust 1.60 #215

This approach would allow kernels to simply use bootloader::logger instead of needing to reinvent the wheel. Any issues with this, @phil-opp?

Made a few more changes to push this Logger API into a more robust state. Still have yet to hear from the maintainer(s).

Thanks for the PR, @kennystrawnmusic! I like the idea to give people a way to quickly add some debug printing to their kernels. However, I don't think that we should export the Logger/LockedLogger API, mainly because I want to avoid the maintenance overhead. There are already good crates for drawing to framebuffers such as embedded-graphics, so I see no reason to duplicate that functionality here.

So I propose the following:

• Add an optional logger feature to this crate that is disabled by default.
• If enabled, make the init_logger function public (and move it from the binary module to the root).
• Keep the logger module private, even if the logger feature is enabled.

This way, we provide an easy way to get some output on the screen when getting started, without needing to provide and maintain a full framebuffer writer implementation. Does this sound good to you?

(I also want to mention that I'm currently working on a rewrite of this crate in the next branch, which will split off a bootloader-api crate. Kernels will only depend on this api crate then, so I'm not sure if we can/should share a logger implementation between the api crate and the main bootloader crate then.)

Closing now — going to open a couple of new PRs in the next couple of hours to make the recommended changes.