Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

seL4_TCB_SetSchedParams: inconsistency between API reference and implementation #1311

Open
alwin-joshy opened this issue Aug 22, 2024 · 1 comment · May be fixed by #1312
Open

seL4_TCB_SetSchedParams: inconsistency between API reference and implementation #1311

alwin-joshy opened this issue Aug 22, 2024 · 1 comment · May be fixed by #1312

Comments

@alwin-joshy
Copy link
Contributor

For the seL4_TCB_SetSchedParams (MCS) invocation, the API reference states the following about the sched_context parameter

If the scheduling context is already bound to a notification or TCB that is not this TCB this operation will fail. Similarly, if this TCB is already bound to a scheduling context that is not this scheduling context, this will also fail.

This does not correspond to the implementation, which adheres to the following:

If the scheduling context is already bound to a notification or TCB, this operation will fail. Similarly, if this TCB is already bound to a scheduling context, this will also fail.

In other words, the operation will fail if the scheduling context passed in is the one that is already bound to the TCB.

@Indanz
Copy link
Contributor

Indanz commented Aug 22, 2024

Indeed it does. Practically that means that seL4_TCB_SetSchedParams can only be called once when creating the TCB for the first time and that it's useless to update parameters later on.

invokeTCB_ThreadControlSched does have a check sc != target->tcbSchedContext, so I think the fix is to add the same exception to decodeSetSchedParams and leave the the API reference as it is.

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 a pull request may close this issue.

2 participants