I like this addition, it makes sense for a driver to be able to "update" a scheduled, but not yet delivered upcall. One change that would make it even more useful is to return the number of upcalls removed, or better yet, an iterator over them. A driver can then use this to reason about whether an upcall was delivered, and consequently whether scheduling another, updated one is necessary or not.

I modified the function so that it returns the number of upcalls removed.
I also added a function to call Process::remove_upcall. In order to get all tasks removed, one could call this function repeatedly instead of calling the remove_pending_upcalls one. To update a task, one could try to remove the task and then schedule an updated upcall.

Since there are no current uses of these methods upstream (at least in this PR), can you an example use case to help reason about the API?

Since there are no current uses of these methods upstream (at least in this PR), can you an example use case to help reason about the API?

Sorry for the delay.

If an app does not call yield often enough, multiple outdated upcalls could pile up.
For example, a capsule could poll all apps to decide if the chip is allowed to enter sleep mode. If an app rarely yields and another one denies each sleep request, the first app would need to respond to multiple old requests, with the risk of filling up the upcall queue.

With this API, the capsule could delete all old requests when issuing a new one.