Not that I know of. It happens in the core crate. The error message is this:
error: could not compile core
Caused by:
process didn't exit successfully: rustc --crate-name core --edition=2018 C:\Users\ethin\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C panic=abort -C embed-bitcode=no -C codegen-units=64 -C debuginfo=2 -C metadata=9503ede77df8d2d8 -C extra-filename=-9503ede77df8d2d8 --out-dir C:\Users\ethin\source\kernel\target\x86_64-kernel-none\debug\deps --target \\?\C:\Users\ethin\source\kernel\x86_64-kernel-none.json -Z force-unstable-if-unmarked -L dependency=C:\Users\ethin\source\kernel\target\x86_64-kernel-none\debug\deps -L dependency=C:\Users\ethin\source\kernel\target\debug\deps --cap-lints allow -C target-feature=+sse,+sse2 (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
warning: build failed, waiting for other jobs to finish...
error: build failed
My target file looks like this:
{
"llvm-target": "x86_64-kernel-none",
"data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
"arch": "x86_64",
"target-endian": "little",
"target-pointer-width": "64",
"target-c-int-width": "32",
"os": "none",
"executables": true,
"linker-flavor": "ld.lld",
"linker": "rust-lld",
"panic-strategy": "abort",
"disable-redzone": true,
"features": "-mmx,+sse,+sse2,+soft-float"
}And my .cargo/config.toml looks like:
[unstable]
build-std = ["core", "compiler_builtins", "alloc"]
[build]
target = "x86_64-kernel-none.json"
rustflags = ["-C", "target-feature=+sse,+sse2"]
[target.'cfg(target_os = "none")']
runner = "bootimage runner"unsafe impl FrameAllocator<Size4KiB> for GlobalFrameAllocator {
fn allocate_frame(&mut self) -> Option<PhysFrame> {
self.pos += 1;
let regions = self.memory_map.iter();
let usable_regions = regions.filter(|r| r.region_type == MemoryRegionType::Usable);
let addr_ranges = usable_regions.map(|r| r.range.start_addr()..r.range.end_addr());
let frame_addresses = addr_ranges.flat_map(|r| r.step_by(4096));
frame_addresses
.map(|addr| PhysFrame::containing_address(PhysAddr::new(addr)))
.nth(self.pos)
}
}trace! macro call in there because it'll get ridiculously spammy. The slowdown happens on both debug and release versions.
It seems to be caused by an LLVM upgrade. You could try the nightly before this upgrade and see whether it is also causing your build issue.
trace! macro call I get more than a thousand messages within the first 30 seconds of boot (and it slows down the boot process like you wouldn't believe). I might make a special function, emited only in debug builds, that allows memory tracing without tracing every single memory allocation that the kernel ever makes.
allocate_phys_range(addr, addr + 4096). Is this not the correct way to compute how large I want the page to be? This seems to work in every other instance except this one, where the allocator just goes haywire (seemingly) trying to allocate all of the RAM of the machine.
scheduler.resched() every 20 ms, which invokes the costly context switch you mentioned in your post. Were you hoping to do something similar where tasks are swapped out at a consistent interval? Overall, I really like how tasks are represented in your kernel, and I think their flexibility would improve the ergonomics of my kernel a lot
@robert-w-gries My basic idea is to define a maximum execution time for tasks, perhaps depending on the number of waiting tasks in the system. If a task runs longer than that, it gets preempted by the timer interrupt to give other tasks the chance to run. This could be implemented by dynamically spawning more threads when encountering long-running tasks. This way, we could avoid most context switches as long as most tasks are I/O bound. The difference to traditional threads that also block when waiting for I/O is that no register state needs to be saved, as the state machine itself saves the minimal state required to continue .
For multi-core systems, we could extend this approach by defining different allowed execution times for different cores. For example, one core could be the batch processing core with a much higher allowed execution time. Tasks that are not latency-critical could be spawned there through an additional spawn_batched method on our executor and avoid the context switch cost this way. Similarly, we could extend our executor with support for latency-critical tasks by lowering the maximum execution time on some CPU cores dynamically.
Of course things get a bit more complicated when you want to schedule user-space programs too. While you could expose a futures-like interface at the system call level and let the kernel do all the task scheduling, you would loose some of the performance benefits because a system call would be required for every userspace task, even if they are very small. So it's probably better to let the user-space program define its own cooperative scheduler and cooperate with the kernel-level scheduler. For example, the kernel-level scheduler could set a "please finish in the next 10ms" flag, which the user-level scheduler could utilize to pause at a convenient point. Of course, user-level programs might not cooperate (they are not trusted), so you still have to implement a traditional preemption mechanism if the program does not respect the flag, but at least you give the user programs the chance of improved performance.
awaits in a single function, the subsequent ones are not executed until the previous ones are finished. Try the future::join method to wait on multiple futures at once. Alternatively, you can spawn the futures as separate tasks in the executor and communicate through channels.
Really impressed with the flexibility of Tasks using your async/await system. The following is valid code inside my kernel_main function:
pub async fn rxinu_main() { kprintln!("TEST TEST TEST") }
let y = 42;
let test = async move |x| { kprintln!("{} {}", x, y); };
executor.spawn(task::Task::new(rxinu_main()));
executor.spawn(task::Task::new(test("The answer is")));Output:
TEST TEST TEST
The answer is 42Task::new boilerplate. Also, I think it would be useful if the spawn method (or a separate method) returned the result of the future similar to thread::spawn in the standard library.
Sounds good! By the way, I found async-std has a 'yield_now' function that works with Futures, and I was able to implement it for my kernel. The usage looks like this:
// do some work
task::yield_now().await;
// do more worksmol runtime instead of async-std, which seems to be a bit more modular. One of its sub-crates is async-task, which seems have no_std support.
no_std, but after looking more into it there's a lot of task functionality that is feature gated behind #[feature(default)] which requires std. I'm surprised because most of the task functionality doesn't need std and would suffice with just alloc. Maybe we can build our own no_std async runtime that extends async-task and keep it under rust-osdev
My code: https://gist.github.com/Lucky4Luuk/d04957d8470030d015a2aedd2c487af2
I'm currently trying to get the VGA writer to work, but I'm running into an issue. After adding the
impl fmt::Write for Writer and adding a write!(writer, "foobar") call, I get this error: no method namedwrite_fmtfound for structWriterin the current scope. Do I have to implement that function too, or am I missing something?