Skip to content

sel4-capdl-initializer: lazy SC rebind for passive#352

Open
dreamliner787-9 wants to merge 2 commits into
seL4:mainfrom
au-ts:passive_task_in_initialiser
Open

sel4-capdl-initializer: lazy SC rebind for passive#352
dreamliner787-9 wants to merge 2 commits into
seL4:mainfrom
au-ts:passive_task_in_initialiser

Conversation

@dreamliner787-9

Copy link
Copy Markdown
Contributor

Implements lazy Scheduling Context rebind for passive tasks inside the capDL initialiser.

Solves problems such as seL4/microkit#91

@dreamliner787-9 dreamliner787-9 requested a review from nspin as a code owner June 22, 2026 05:15
Add `fn bind_ntfn` for `SchedContext`.

Signed-off-by: Bill Nguyen <bill.nguyen@unsw.edu.au>
@dreamliner787-9 dreamliner787-9 force-pushed the passive_task_in_initialiser branch from 7dbba7a to 561c46e Compare June 22, 2026 05:18
Comment on lines +841 to +845
if obj.bound_notification().is_none() {
panic!("A passive task must have its own Notification.");
}
let bound_notification_cap =
self.orig_cap::<cap_type::Notification>(obj.bound_notification().unwrap().object);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Use the let/Some destrucuturing (or match) here rather than is_none() and unwrap.

Also, if we do sc.bind_ntfn(), where is that SC from, if not obj.sc() and does that not imply that it is not none?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

sc in this context could be the initialiser's SC or the TCB's SC as created from the spec. Binding the Notification to the initialiser's SC wouldn't make sense so that's why I had the if obj.bound_notification().is_none() check.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

But I'm confused, you then do sc.bind_ntfn(bound_notification_cap)?; next?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Wait my bad, in the original comment, sc would be either a Null cap or the TCB's SC as created from the spec.

Regardless, the if obj.sc().is_none() { check will make sure that sc is the TCB's SC.

Then bound_notification_cap is the TCB's Notification cap.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Then I think we should be explicit and use let/Some for that as well instead of using the previous sc.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ok sounds good

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I meant bound_sc here on the next line, not still sc. No point unwrapping to an unused var.

Also, I'd suggest using this variant:

let Some(bound_sc) = obj.sc() else {
   panic!("blah blah");
}

This removes the nested as you add more checks.

(Also, is panic!() the normal way that you do errors in rust-sel4?)

Implements lazy Scheduling Context rebind for passive tasks inside
the capDL initialiser.

Signed-off-by: Bill Nguyen <bill.nguyen@unsw.edu.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants