RFC: Boot Orchestration Component #1013
Conversation
github-actions
bot
added
impact:non-functional
kat-perez
force-pushed
the
rfc-boot-manager
branch
from
d8f1790 to
6c56b0a
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
kat-perez
force-pushed
the
rfc-boot-manager
branch
from
6c56b0a to
609504f
Compare
os-d
left a comment
os-d
left a comment
There was a problem hiding this comment.
The biggest part of BDS that I did not see enumerated in this RFC is the connect management, driving binding protocols, etc. That requires careful thought as it is another form of driver dispatch that is unique to the BDS phase.
I think that before we move this forward, we need to include what that story is.
kat-perez
force-pushed
the
rfc-boot-manager
branch
5 times, most recently
from
ec79517 to
db8fc97
Compare
|
i've changed the design quite a bit, added more goals and requirements to further constrain the design to be limited to the most fundamental Patina components that can achieve a successful boot |
|
|
||
| To discover bootable media, the Boot Manager connects storage device controllers (via `ConnectController()`) to | ||
| enable file system drivers and scan for boot loaders. BootOptionDiscovery accepts connection strategies as | ||
| configuration, allowing platforms to customize which devices get connected while using the shared ProtocolServices |
There was a problem hiding this comment.
For a first implementation, I think it is fine to leave the connect controller flow to the protocol, but if we look forward to how Patina components would be implemented that interact with the connect controller flow, we wouldn't want a protocol, we'd want a service and it may look very different from the protocol.
It's fine not to define that here, if that is not in scope initially, but I would at least note that that work is deferred to a future RFC and this RFC does not support native Patina components interacting with the connect controller flow.
There was a problem hiding this comment.
good point. I've added an explicit "Future Work: Connect Controller Service" section noting that this is deferred and native Patina components cannot participate in the connect controller flow in this RFC.
| ## Goals | ||
|
|
||
| 1. Provide UEFI spec compliant boot functionality | ||
| 2. Enable platforms to boot with zero custom code using reference components |
There was a problem hiding this comment.
This statement may read as a platform does not need any custom code to boot, i.e. just taken patina as is and you are good, which is not what you intend. Consider rewriting this as something like:
Enable platforms to use a common boot manager without customization
There was a problem hiding this comment.
Goal #2 reworded like this:
- Enable platforms to use a common boot manager without customization
kat-perez
force-pushed
the
rfc-boot-manager
branch
3 times, most recently
from
d488f8b to
380ee34
Compare
kat-perez
changed the title
kat-perez
force-pushed
the
rfc-boot-manager
branch
10 times, most recently
from
260e43c to
30ec240
Compare
kat-perez
force-pushed
the
rfc-boot-manager
branch
from
30ec240 to
43371f5
Compare
kat-perez
force-pushed
the
rfc-boot-manager
branch
from
43371f5 to
7a68005
Compare
kat-perez
force-pushed
the
rfc-boot-manager
branch
from
7a68005 to
b90bc0c
Compare
kat-perez
force-pushed
the
rfc-boot-manager
branch
from
b90bc0c to
411136c
Compare
6 participants
Description
This RFC proposes modular components for UEFI spec compliant boot functionality in Patina firmware. Platforms can
use reference implementations for console initialization, boot option discovery, and boot orchestration,
or implement custom boot flows using the provided library functions.
How This Was Tested
N/A
Integration Instructions
N/A