Philipp Oppermann
Philipp Oppermann
Here: https://github.com/rust-osdev/x86_64/blob/f8a3d70a28f0ae41fe912d34060a30d0176d1541/src/structures/paging/mapper/offset_page_table.rs#L53 The physical address space is larger than the virtual one, so this can overflow on some architectures (e.g. see #289). It can also overflow when `offset` is large....
This will make it possible to use Rust's native range types instead of our custom `PhysFrameRange`, `PageRange`, etc types. Note that we still need to keep these old types as...
This is a draft for the upcoming _"This Month in Rust OSDev: August 2022"_ post. Please add your content to this draft by creating a pull request against the `next`...
The `serde` feature is active by default because the `std` feature depends on it: https://github.com/00imvj00/mqttrs/blob/17cc76e1ada477feeae72820345ba1e2144376c8/Cargo.toml#L17-L22 This makes it impossible to build the library with only the `std` feature, but not...
This is a draft for the upcoming "This Month in Rust OSDev: October 2022" post. Please add your content to this draft by creating a pull request against the next...
Hi, I just stumbled over: https://github.com/Lokathor/bytemuck/blob/c705218630d0a11af39b39a1c7639de6dce04db3/src/offset_of.rs#L60-L65 Wouldn't it be possible to do this safely using the [`core::ptr::addr_of` macro](https://doc.rust-lang.org/stable/core/ptr/macro.addr_of.html) to calculate the offset?
Since the CDR format is not self-describing, the target type needs to be known for deserialization. The current RustDDS implementation ensures this by requiring a `serde::Deserialize` implementation for all target...
This is for example useful for a producer/consumer use-case, where the consumer is not permitted to modify the data.
See https://github.com/rust-osdev/bootloader/pull/420 We worked around the issue for now by preventing inlining of the `map_physical_region` function, but we should figure out the root cause of this.
Right now the BIOS implementation does not consider the framebuffer configuration of the kernel. Instead, it just defaults to a hardcoded resolution. To fix this, we would need to parse...