Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

bradjc
Copy link
Contributor

@bradjc bradjc commented Oct 16, 2025

Pull Request Overview

This pull request moves the schedulers to capsules. This ends up being a bit more involved for two reasons:

  1. The priority scheduler uses internal APIs to the kernel crate that it can't access in capsules. I changed the implementation to use iter.enumerate() instead of the ProcessId.index as the priority.
  2. Moving the capsules means the import in every board has to change. Rather than change that I updated the components to use types so that the component instantiation is copy-and-pasteable. This gets us closer to easier to auto generate main.rs files.

Testing Strategy

travis

TODO or Help Wanted

Blocked on the PR to remove unsafe from the scheduler trait.

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

@github-actions github-actions bot added kernel WG-OpenTitan In the purview of the OpenTitan working group. component labels Oct 16, 2025
Copy link
Member

@alevy alevy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really great!

I'm not convinced it makes sense to have these type declarations in the components, rather than basically expand the type declaration in each board.

Either way the name SchedulerObj is wrong.

Otherwise looks good to me.

64,
>;

type SchedulerObj = components::sched::round_robin::RoundRobinComponentType;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bike-shedding the name for this:

  • It's not an object. Arguably Rust doesn't have objects at all, and this is certainly is not one.
  • SchedulerType?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Obviously, this would apply to all the boards and is hopefully just sed -i 's/type SchedulerObj/type SchedulerType/' boards/**/main.rs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like "Type" because everything is a type.

Here is what has emerged so far:

  • Hw: For types which are the specific hardware for a resource/hil. Example: type AlarmHw = nrf52840::nrf5x::rtc.
  • Driver: For types which are syscall drivers. Example: type AlarmDriver = capsules_core::alarm::Alarm.

I think for both of those, type would be suitable, ie AlarmType and then AlarmType again.

I think we would benefit from a class that has a generic feel. Any ideas other than "type"? I used obj only because it was something to use and easy to replace later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps something that helps with the semantic implications here, SchedulerChosen (SchedulerUsed, SchedulerSelected, ...)? i.e., you pass the scheduler you chose (in the same way that you pass the HW you instantiate) to generic Scheduler interfaces?

@alevy
Copy link
Member

alevy commented Oct 16, 2025

Testing Strategy

travis

We haven't used travis for nearly a decade 😛

@bradjc
Copy link
Contributor Author

bradjc commented Oct 17, 2025

Testing Strategy

travis

We haven't used travis for nearly a decade 😛

Feels like just yesterday.

Copy link
Member

@ppannuto ppannuto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me (pending the name bikeshed)

.find(|proc| proc.ready())
.is_some_and(|ready_proc| {
self.running.map_or(false, |running| {
ready_proc.processid().index < running.index
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth flagging here that switching from using processid() to enumerate() actually fixes a potential correctness issue since the priority scheduler claims to prioritize based on process slot order, but the default process id implementation might not preserve the invariant of processid order matching slot order in the face of dynamic processes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component kernel WG-OpenTitan In the purview of the OpenTitan working group.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants