Closed DemesneGH closed 2 weeks ago
Over the past few years, we’ve heard varying perspectives from the community regarding the needs for OPTEE Trusted Application (TA) development. Here’s a brief summary:
master
branch: This allows the use of Rust crates requiring std, which is beneficial for more feature-rich development. However, it may face delays in upstream Rust std support.no-std
branch: This is suited for TAs with limited functionality, ensuring minimal dependencies and a lightweight codebase.I assume the proposed changes aim to address the needs of both groups while minimizing maintenance efforts. In addition, could you please elaborate on the following points if this change is merged?
no-std
and master
?main
, master
, and no-std
branches?
Thanks.@m4sterchain Yes this proposal mainly aims to simplify future development and maintenance. Since most of the code is shared between std
and no-std
, merging them into main
will eliminate the work to sync pull requests and changes.
- What will be the impact on the development of TAs that depend on
no-std
andmaster
?
The build process remains mostly the same (run $ make
), but there are minor differences:
For no-std
developers: No additional steps are required. Development keeps same as the original no-std
branch.
For std
developers: Developers will need to run $ export STD=y
to enable the std
feature before running $ source environment
.
- What are the long-term development plans for maintaining the
main
,master
, andno-std
branches?
Current Status:
no-std
: A clean branch dedicated to no-std
development.
master
: The legacy branch used for std
development, and the primary development branch until 2024.
main
: New branch forked from no-std
, this branch adds std
building support.
After setting main
as the default branch (proposed in this VOTE):
The no-std
branch will be deprecated.
The master
branch will be deprecated.
The main
branch will become the only maintenance branch, supporting both std
and no-std
.
Long-Term Development Plan for the main
Branch:
Add std
-specific examples. Since the purpose of std
is to provide functionalities that no-std
cannot, we can offer examples such as Serde and TLS, which already provided in master
branch but not merged into main
yet.
Upstream the OP-TEE target as a Rust Tier 3 target.
Develop demo projects for specific scenarios, such as Web3.
For the reference and clarification, these are the summary of all files in SDK (main
branch) root path and their relation with development mode, the "std
only" means this file is used only if std is enabled.
files / directories | description | shared / std only / no-std only |
---|---|---|
.github/workflows, ci, tests | Test both std and no-std for 32-bit and 64-bit TAs. The build is determined by ARCH_HOST , ARCH_TA , and STD environment variables. |
Shared |
optee-teec | Core library for CA (Client Application). | Shared |
optee-utee | Core library for TA (Trusted Application). Most of the code is shared, with minor target-specific differences determined by target_os (optee for std , linux for no-std ). |
Shared |
examples | Code remains the same; ta/Makefile selects the appropriate build tool: cargo for std , Xargo for no-std . |
Shared |
setup.sh | Installs Rust, cargo , and gcc . |
Shared |
build_optee_libraries.sh | Builds the necessary OP-TEE libraries for CA and TA, if not available. | Shared |
environment | Sets toolchain and library paths. | Shared |
rust-toolchain.toml | Specifies the Rust toolchain version. | Shared |
aarch64-unknown-optee.json | Specification for AARCH64 OP-TEE target. | std only |
arm-unknown-optee.json | Specification for ARM32 OP-TEE target. | std only |
all Xargo.toml files |
Xargo configuration files pointing to the customized std path. |
std only |
setup_std_dependencies.sh | Downloads the ported std for OP-TEE. |
std only |
LICENSE files, docs, etc. | Documentation and licenses. | Shared |
@m4sterchain Could you help to review this PR for main
:https://github.com/apache/incubator-teaclave-trustzone-sdk/pull/144 ? After this PR merged I think main
is ready to be set as default branch.
Yes this proposal mainly aims to simplify future development and maintenance. Since most of the code is shared between std and no-std, merging them into main will eliminate the work to sync pull requests and changes.
+1 for this proposal.
Close as completed.
The vote has opened on: https://lists.apache.org/thread/46sgblqjolxfro42ot7ttv577mqv49xz If you have any comments, please feel free to reply to that thread or this issue. Thanks!