The Logger API needs to be in the top level of bootloader for Edition-3-Post-3 to go anywhere

[kennystrawnmusic]

Submitted pull request rust-osdev/bootloader#218 to expose the bootloader's Logger API to kernels for them to use it — because wrapping it inside bootloader::binary doesn't allow for this: the features = binary property causes the bootloader to panic if a kernel tries to put it inside of its own Cargo.toml; yet, importing the Logger is the only way for kernels to interact with the bootloader in its current state. So, this contribution does 4 things:

1. Moves all 4 of the logger's dependency crates out of binary = and into default = in the bootloader's Cargo.toml
2. Moves bootloader::binary::logger to bootloader::logger so that kernels can use it without making the bootloader panic
3. Makes all of the Logger's member functions public and documents them
4. Adds a pub use crate::logger line to bootloader/src/binary/mod.rs for backward compatibility

This change should make it possible for any kernel to define its own logger simply by importing the bootloader's backend — which should then go on to make post-3 of the third edition much easier to write.

[phil-opp]

Thanks for the PR, I left a comment there.

Even if we export the logger API from the bootloader crate, I don't think that I'll use it for the third post. I want to explain how a framebuffer works, so I want to create a basic custom implementation from scratch. Afterwards, I plan to use the embedded-graphics crate, which provides lots of advanced features.

[kennystrawnmusic]

Thanks, that is a much better idea because embedded_graphics also allows for better use of colors in the framebuffer and possibly even kernel-mode window geometry structures anyway.