[FCP] RFC: Consolidate common core code into a single internal library crate#1594
Conversation
This RFC proposes creating an internal crate (`core/patina_internal_lib`) for code shared by core implementations. This single crate would remove overhead and simplify changing internal code and interfaces. This will become increasingly important with the introduction of the Standalone MM core. This RFC builds on the crate organization and naming conventions established by [RFC: Categorizing and Renaming Patina Crates for Consistency](./0007-patina-crates-naming-and-categorization.md).
github-actions
Bot
added
impact:non-functional
✅ QEMU Validation PassedAll QEMU validation jobs completed successfully.
Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/28843110485 Boot Time to EFI Shell
Dependencies
This comment was automatically generated by the Patina QEMU PR Validation Post workflow. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Agree with the general motivation of the RFC, but one of the original motivations for several smaller crates was to help clarify/enforce separation of concerns. With everything in a large monocrate, it becomes cheaper to cross-couple things. Are there any organizational or technical mechanisms that we could retain to help with that motivation? |
os-d
left a comment
os-d
left a comment
There was a problem hiding this comment.
I don’t have strong feelings on this one. A small nit, naming is hard, but patina_internal_lib feels a bit too generic, maybe patina_internal_core to indicate its use?
@joschock, this is true. I think this will be similar to the SDK where we perhaps need to define some rules and enforce them as practice instead of technologically. That is, on us as the maintainers and reviews to prevent bad code design from making it in. I was thinking about adding a "Here are the rules for this crate", but I think until the crate matures it's probably difficult to say what they should be exactly. Do you have any ideas what types of rules you'd like to see? |
Yeah, |
makubacki
left a comment
makubacki
left a comment
There was a problem hiding this comment.
I think it makes sense to step back and reduce our crate footprint for content we do not intend to be consumed outside a small set of core code.
It's less Patina-related crate noise in the registry and scales more sustainably as noted in the RFC. To my understanding, our sharing boundary at the crate level is largely "core consumption only" and the content separation, documentation, and access details can be handled within the module system. Also, as noted we can always split off crates meaningfully when we find justification to do so.
|
Added draft PR: #1597 |
cfernald
changed the title
|
It seems we have reached agreement. Moving to FCP. |
Merges existing `patina_internal_depex` and `patina_internal_collections` into a new more common `patina_internal_core` to reduce overhead and process for adding new shared code for the Patina DXE, MM, and supervisor cores. Implementation for RFC: #1594
6 participants
Description
This RFC proposes creating an internal crate (
core/patina_internal_lib) for code shared by core implementations. This single crate would remove overhead and simplify changing internal code and interfaces. This will become increasingly important with the introduction of the Standalone MM core.This RFC builds on the crate organization and naming conventions established by RFC: Categorizing and Renaming Patina Crates for Consistency.
How This Was Tested
N/A
Integration Instructions
N/A