Kevin Boos

icon indicating a website link https://www.theseus-os.com/kevinaboos/

icon company @futurewei-tech, @theseus-os icon location Bellevue, Washington icon location Open-source Rust developer. Principal Architect at @futurewei-tech. Tech lead for @project-robius. Creator of @theseus-os. PhD, Rice University

Results 327 comments of Kevin Boos

Remove patches from `Cargo.toml`

- `spin`: we can probably just use the upstream directly; that needs some testing though to ensure system perf isn't affected. - `volatile`: our fork of `volatile` has diverged significantly...

Replace `unwrap_or` with `unwrap_or_else` and vice versa depending on cost of computing argument

Hi @xa888s, it appears that there are still quite a few unrelated formatting changes in this branch. Once you remove those, I am happy to review and accept this PR....

Replace `unwrap_or` with `unwrap_or_else` and vice versa depending on cost of computing argument

Closing due to inactivity and unrelated changes in favor of #641.

Use preemption-safe locks instead of interrupt-safe locks wherever possible

This is now in progress since #595 is merged. I will first work on using preemption guards in scheduling and task management, since that's the clearest avenue for efficiency wins.

Use preemption-safe locks instead of interrupt-safe locks wherever possible

As I mused earlier, another good idea may be to introduce a more fine-grained interrupt-safe lock crate that disables only certain interrupts by masking those IRQs. For example, if a...

Use preemption-safe locks instead of interrupt-safe locks wherever possible

#600 paves the way for properly handling (enabling/disabling) preemption and interrupts during task switching.

Use preemption-safe locks instead of interrupt-safe locks wherever possible

#603 implements this for `schedule()` and `task_switch()`

Use preemption-safe locks instead of interrupt-safe locks wherever possible

#616 implements this for task lifecycle functions that cleanup task states after a task has exited.

Use preemption-safe locks instead of interrupt-safe locks wherever possible

I think the only remaining obvious area for this is runqueue management, which I can tackle soon.

Use preemption-safe locks instead of interrupt-safe locks wherever possible

With #629 merged in, I think this issue can be closed. Looking through the code base, the only other areas where interrupt-safe locks could be removed are: * the heap...