Move ResetVector to a dedicated crate #73
Conversation
|
Any special reason to introduce a new crate? I have concern because then we need document multiple interfaces, such as BSP->C code, mailbox wakeup etc. |
Separate TDX ResetVector into a dedicate crate tdx-bootstrap, so the td-shim could be platform indenpendent. Signed-off-by: Liu Jiang <[email protected]>
Move code from rust-tdshim/ResetVector into tdx-bootstrap. Signed-off-by: Liu Jiang <[email protected]>
Minor doc and syntax changes. Signed-off-by: Liu Jiang <[email protected]>
Define constants which may used by td-shim. Signed-off-by: Liu Jiang <[email protected]>
jiangliu
force-pushed
the
tdx-bootstrap
branch
from
d19993e to
c682817
Compare
The idea is to isolate platform dependent code from platform independent code. So the tdx-bootstrap will host ResetVector and other TDX specific code, and we may use feature to control platform dependent code in td-shim:) |
Personally, I feel it is an overdesign and I am not sure if it is feasible. I am OK to rename and refactoring. But I don't think we need create a dedicated crate - at least not at this moment. |
|
@jiangliu , Do you want to keep the refactoring work, just drop the standalone crate? I do see the value for the refactoring work. |
I still hope to split out the reset vector as td-bootstrap or tdx-bootstrap:) |
|
I think we can isolate the code. Or any refactoring/rename is welcome. My concern is to create a standalone crate, because a standalone crate means a clear interface. If we really really want to create a standalone crate, I think we must document in td-bootstrap clearly, including but not limited to:
That becomes a mini Td-Shim spec ... |
|
Hi @jiangliu - what do we need to do to progress this? |
Move ResetVector to a dedicated crate