[feature/patina-boot] patina_boot: Add ConnectController service trait

[kat-perez]

Description

Add a pluggable ConnectController trait for controller connection strategies during device enumeration, replacing the hardcoded connect_all() call in SimpleBootManager.

• ConnectController trait with single connect() method
• ConnectAllStrategy default implementation (preserves existing behavior)
• SimpleBootManager::with_connect_strategy() constructor for custom strategies
• interleave_connect_and_dispatch() made generic over the connection function

This enables platforms to implement selective device enumeration (e.g., PCI-only, skip USB for headless) without writing a full custom BootOrchestrator.

SimpleBootManager::new() behavior is unchanged — zero breakage for existing platforms.

Ref: OpenDevicePartnership/modern-payload#205

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• 55 unit tests passing (7 new: custom connect function success/failure, connect strategy constructors, interleave with custom closures)
• cargo fmt, cargo clippy clean
• Integration tested with patina-dxe-core-qemu on QEMU Q35 — full boot to UEFI Shell 2.0

Integration Instructions

No changes required for existing platforms. SimpleBootManager::new() defaults to ConnectAllStrategy.

Platforms wanting selective enumeration use the new constructor:

add.component(BootDispatcher::new(SimpleBootManager::with_connect_strategy(
    config,
    MyCustomStrategy,
)));

[patina-automation]

✅ QEMU Validation Passed

All QEMU validation jobs completed successfully.

Note: Q35 is only built on Windows hosts (QEMU boot is disabled due to a QEMU vfat issue).

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/24726937050

Boot Time to EFI Shell

Platform	Elapsed
Q35 (Linux Host)	27.0s
SBSA (Linux Host)	1m 6s

Dependencies

Repository	Ref
patina	33fb729
patina-dxe-core-qemu	c3f2338
patina-fw-patcher	3960603
patina-qemu firmware	v3.0.0
patina-qemu build script	e626337

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.

[codecov]

Codecov Report

❌ Patch coverage is 93.95973% with 9 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
components/patina_boot/src/connect_controller.rs	0.00%	3 Missing ⚠️
...mponents/patina_boot/src/strategies/connect_all.rs	0.00%	3 Missing ⚠️
.../patina_boot/src/strategies/connect_by_protocol.rs	96.94%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[os-d]

I'm not as clear on what defines the Simple Boot Manager any more if the connect strategy is configurable. Besides connectall, what is the Simple Boot Manager doing that an "Advanced" Boot Manager wouldn't do or conversely, what isn't it doing?

i.e. it seems you are making Simple Boot Manager a more generic component than originally designed, which is fine, but perhaps the design point should be revisited on whether this is really just Simple or whether it is something that may extend to more platforms.

[os-d]

This seems a reasonable approach, for some platform it knows it only wants to connect NVMe devices, for example, but would appreciate others more familiar with BDS than me to weigh. @makubacki @apop5 @kuqin12 ?

[kat-perez]

@os-d

I'm not as clear on what defines the Simple Boot Manager any more if the connect strategy is configurable. Besides connectall, what is the Simple Boot Manager doing that an "Advanced" Boot Manager wouldn't do or conversely, what isn't it doing?

I can describe a bit better the expectations for SimpleBootManager and this is something I would add in the documentation:

A declarative boot manager for platforms with static boot topologies — as opposed to a full UEFI BDS with variable-driven BootOrder and menu UI. Each phase (enumeration, hotkey dispatch, boot selection, failure) is a pluggable strategy with sensible defaults.

[os-d]

A declarative boot manager for platforms with static boot topologies — as opposed to a full UEFI BDS with variable-driven BootOrder and menu UI. Each phase (enumeration, hotkey dispatch, boot selection, failure) is a pluggable strategy with sensible defaults.

Thanks. As it evolves, particularly with this notion of the pluggable strategies, I'm wondering whether the SimpleBootManager is becoming just a BootManager and one set of strategies is the "Simple" set and another set may include variable driven boot order, boot menu, etc.

[kat-perez]

A declarative boot manager for platforms with static boot topologies — as opposed to a full UEFI BDS with variable-driven BootOrder and menu UI. Each phase (enumeration, hotkey dispatch, boot selection, failure) is a pluggable strategy with sensible defaults.

Thanks. As it evolves, particularly with this notion of the pluggable strategies, I'm wondering whether the SimpleBootManager is becoming just a BootManager and one set of strategies is the "Simple" set and another set may include variable driven boot order, boot menu, etc.

Yeah, that's true that it's not really "Simple" anymore. The "simple" term feels overloaded / unclear for what this implementation is achieving. How about something like StaticBootManager or do you have any other recommendations for naming?

[os-d]

A declarative boot manager for platforms with static boot topologies — as opposed to a full UEFI BDS with variable-driven BootOrder and menu UI. Each phase (enumeration, hotkey dispatch, boot selection, failure) is a pluggable strategy with sensible defaults.

Thanks. As it evolves, particularly with this notion of the pluggable strategies, I'm wondering whether the SimpleBootManager is becoming just a BootManager and one set of strategies is the "Simple" set and another set may include variable driven boot order, boot menu, etc.

Yeah, that's true that it's not really "Simple" anymore. The "simple" term feels overloaded / unclear for what this implementation is achieving. How about something like StaticBootManager or do you have any other recommendations for naming?

I think we can revisit the naming later if needed, I'm mostly thinking on the architectural side of this. Perhaps in the next Patina meeting we can discuss this with the group, to help with my understanding. Like I said, as more of the SimpleBootManager becomes pluggable, I'm not as sure the decisions being made in the SimpleBootManager that aren't relevant for other platforms.