Virt/selection policy by frihetselsker · Pull Request #13 · OxidosAutomotive/tock

frihetselsker · 2026-04-21T08:14:07Z

Pull Request Overview

This pull request fixes the fairness problem of virtual devices. So far it only implements it for the UART Mux, but if approved, the same fix will be easily implemented for the rest of the affected Muxes.

The Fairness Problem

When searching for the next operation, multiplexers (except the Alarm) will always iterate the devices list from beginning to end. This means that if one device always has a job and it was inserted earlier, it will always be picked.

The following examples illustrates the problem for the UART Mux. If debug!() is called frequently (for example in the UartMux), the DebugConsole has a monopoly over the UART Multiplexer, as it will be the only devices chosen to print.

Solution

We introduce the SelectionPolicy trait that provides Muxes with the device selection logic. It is a generic type and should not add any overhead, neither in speed, neither in code space.

We define two policies:

InsertionFirstPolicy that behaves like Muxes used to behave so far, it iterates the list from the beginning to the end. This provides backward compatibility.
RoundRobinPolicy that iterates the devices list in a round robin manner. Using this policy with the previous debug! examples allows all device to print.

This solution offers a structural change that gives users the freedom to choose the policy they want. By default, the UART Mux uses the InsertionFirstPolicy and there are no changes required in the code.

Users will now able to implement their own selection policies for the UART Mux.

Testing Strategy

This pull request was tested by using a custom kernel of qemu_rv32_virt with UART peripheral, and three equivalent applications that try to use printf() simultaneously.

TODO or Help Wanted

Feedback

Documentation Updated

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

We are unsure of the proper placement of the documentation in the README file. Help is needed here as well.

Formatting

Ran make prepush.

AI Use

The PR description details my use of AI in the production of the
code in this PR, if any, and I have manually checked and
personally certify the entire contents of this PR.

alexandruradovici · 2026-04-21T12:30:39Z

 - **[Virtual SPI](src/virtualizers/virtual_spi.rs)**: Shared SPI and fixed chip select pins.
 - **[Virtual Timer](src/virtualizers/virtual_timer.rs)**: Shared timer.
 - **[Virtual UART](src/virtualizers/virtual_uart.rs)**: Shared UART bus.
+- **[Selection Policy](src/virtualizers/selection_policy.rs)**: Policy that determines which device is selected first.


Suggested change

- **[Selection Policy](src/virtualizers/selection_policy.rs)**: Policy that determines which device is selected first.

selected first.

This is not a capsule, I would not add it in this list.

alexandruradovici · 2026-04-21T12:44:36Z

+        }
+    }
+
+    // Constructor with an option for custom selection policy


Suggested change

// Constructor with an option for custom selection policy

/// Create a new Mux with a custom selection policy.

Detail this please.

alexandruradovici · 2026-04-21T12:45:12Z

-impl<'a> MuxUart<'a> {
-    pub fn new(uart: &'a dyn uart::Uart<'a>, buffer: &'static mut [u8], speed: u32) -> MuxUart<'a> {
+impl<'a, P: SelectionPolicy<&'a UartDevice<'a, P>>> MuxUart<'a, P> {
+    // Backward compatible constructor


Suggested change

// Backward compatible constructor

/// Create a new Mux with the [`InsertionFIrstPolicy`] selection policy.

alexandruradovici · 2026-04-21T12:46:30Z

+
+use core::cell::Cell;
+
+pub trait SelectionPolicy<I> {


Document teh trait.

eva-cosma

The code itself looks good, just a few comments about the documentation.

I would try to document the SelectionPolicy less as "what device is chosen first" and more as in "in what order the devices are selected for execution". Purely code-wise, yes, we determine what the "first" element that matches our criteria is, that is completely true, but functionally we determine what is the order of execution. Moreso, SelectionPolicy can also be used as a prioritization mechanism.

I'm not going to block the PR from being upstreamed with this documentation, since this is a minor thing, just to improve clarity and for it to be easier to understand what the grand scope of this selection policy is.

As a sidenote, my rule-of-thumb when it comes to documentation is "try to answer first 'Why?' not 'How?'". Why do we need a selection policy? After that, How do I use a selection policy?

eva-cosma · 2026-04-22T09:38:44Z

+            $P
+        )
    };
+    // Added for backward compatibility


Suggested change

// Added for backward compatibility

// By default, if no selection policy is provided we will use the `InsertionFirstPolicy`. This option has been chosen as the default to maintain backwards compatibility.

eva-cosma · 2026-04-22T09:43:15Z

 - **[Virtual SPI](src/virtualizers/virtual_spi.rs)**: Shared SPI and fixed chip select pins.
 - **[Virtual Timer](src/virtualizers/virtual_timer.rs)**: Shared timer.
 - **[Virtual UART](src/virtualizers/virtual_uart.rs)**: Shared UART bus.
+- **[Selection Policy](src/virtualizers/selection_policy.rs)**: Policy that determines which device is selected first.


Suggested change

- **[Selection Policy](src/virtualizers/selection_policy.rs)**: Policy that determines which device is selected first.

- **[Selection Policy](src/virtualizers/selection_policy.rs)**: Policy that determines in what order the virtual peripherals are selected for execution.

Feel free to change the phrasing a bit on this one.

eva-cosma · 2026-04-22T09:43:59Z

See my main comment regarding first

eva-cosma · 2026-04-22T09:51:49Z

@alexandruradovici is the benchmark failing due to @frihetselsker 's code, or due to something on the repo that should pass when we upstream this PR?

alexandruradovici · 2026-04-22T09:53:10Z

The code itself looks good, just a few comments about the documentation.

I would try to document the SelectionPolicy less as "what device is chosen first" and more as in "in what order the devices are selected for execution". Purely code-wise, yes, we determine what the "first" element that matches our criteria is, that is completely true, but functionally we determine what is the order of execution. Moreso, SelectionPolicy can also be used as a prioritization mechanism.

I'm not going to block the PR from being upstreamed with this documentation, since this is a minor thing, just to improve clarity and for it to be easier to understand what the grand scope of this selection policy is.

As a sidenote, my rule-of-thumb when it comes to documentation is "try to answer first 'Why?' not 'How?'". Why do we need a selection policy? After that, How do I use a selection policy?

@frihetselsker can you apply the changes to the documentation?

frihetselsker · 2026-04-22T10:08:36Z

On it

github-actions Bot added component kernel labels Apr 21, 2026

frihetselsker marked this pull request as draft April 21, 2026 08:19

alexandruradovici requested changes Apr 21, 2026

View reviewed changes

Comment thread boards/nucleo_f446re/src/virtual_uart_rx_test.rs

Comment thread capsules/core/src/virtualizers/selection_policy.rs Outdated

Comment thread capsules/core/src/virtualizers/selection_policy.rs Outdated

alexandruradovici requested changes Apr 21, 2026

View reviewed changes

alexandruradovici reviewed Apr 22, 2026

View reviewed changes

Comment thread capsules/core/src/virtualizers/selection_policy.rs Outdated

frihetselsker force-pushed the virt/selection_policy branch from 312dd1d to 33269b3 Compare April 22, 2026 08:47

eva-cosma reviewed Apr 22, 2026

View reviewed changes

frihetselsker force-pushed the virt/selection_policy branch from 33269b3 to 2da4851 Compare April 22, 2026 10:13

feat: selection policy in UART virtualizer

1a37768

frihetselsker force-pushed the virt/selection_policy branch from 2da4851 to 1a37768 Compare April 30, 2026 07:42

	- [Selection Policy](src/virtualizers/selection_policy.rs): Policy that determines which device is selected first.
	selected first.

	// Constructor with an option for custom selection policy
	/// Create a new Mux with a custom selection policy.

	// Backward compatible constructor
	/// Create a new Mux with the [`InsertionFIrstPolicy`] selection policy.

	// Added for backward compatibility
	// By default, if no selection policy is provided we will use the `InsertionFirstPolicy`. This option has been chosen as the default to maintain backwards compatibility.

Uh oh!

Conversation

frihetselsker commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Overview

The Fairness Problem

Solution

Testing Strategy

TODO or Help Wanted

Documentation Updated

Formatting

AI Use

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alexandruradovici Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alexandruradovici Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

alexandruradovici Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

alexandruradovici Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

eva-cosma left a comment

Choose a reason for hiding this comment

Uh oh!

eva-cosma Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

eva-cosma Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

eva-cosma Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

eva-cosma commented Apr 22, 2026

Uh oh!

alexandruradovici commented Apr 22, 2026

Uh oh!

frihetselsker commented Apr 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

frihetselsker commented Apr 21, 2026 •

edited

Loading