m4sterchain commented on PR #245:
URL:
https://github.com/apache/teaclave-trustzone-sdk/pull/245#issuecomment-3585190298
> # cargo-optee Testing Report and Findings
> Below is a consolidated report of issues, observations, and suggestions
identified during testing of `cargo-optee` in PR #245. I include reproducible
examples, analysis, and potential directions for improvement.
>
> ## 1. Issue: `std` Flag Logic Bug
> ### Description
> The CLI parameter `--std` is parsed as a bool, and later converted into
`Option<bool>` (`cmd_std`). However, the current logic contains an unintended
behavior:
>
> * When the user does not pass `--std`, the default value `std = false`
becomes `Some(false)`
> * As a result, `cmd_std` never becomes `None`
> * Therefore, `BuildConfig::resolve()` never falls back to the
configuration defined in `Cargo.toml`
>
> This causes the `std` parameter to never fall back to the configuration
provided in `Cargo.toml`.
>
> ### Quick Fix (tested and working)
> Changing the following argument inside `BuildConfig::resolve()`:
>
> ```rust
> # cargo-optee/main.rs:79
> if std { Some(true) } else { None }
> ```
>
> This restores correct fallback behavior, but it is only a temporary
workaround.
>
> ### Suggested Solutions
> 1. Introduce explicit CLI flags:
> `--std`
> `--no-std`
> 2. Or, treat `std`/`no-std` as features selection:
> `--features std`
> `--features no-std`
>
> Feedback from maintainers would be appreciated; I am willing to contribute
a proper solution.
>
> ## 2. Issue: `--manifest-path` Relative Path Resolution in mnist-rs
> ### Description
> I encountered an issue related to path resolution in `cargo-optee`. The
behavior is inconsistent between `mnist-rs` and other examples such as
`hello_world-rs` and `acipher-rs`. Since the root cause is not yet clear to me,
I would like to ask for guidance or insights from the community.
>
> Below are the reproducible cases.
>
> 1. Case 1 — Running inside the Cargo.toml directory (`hello_world-rs`)
>
> `Cargo.toml` is
>
> ```toml
> ...
> [package.metadata.optee.ta]
> arch = "arm"
> std = true
> uuid-path = "../uuid.txt"
> ta-dev-kit-dir = { aarch64 =
"/opt/teaclave/optee/optee_os/out/arm-plat-vexpress/export-ta_arm64", arm =
"/opt/teaclave/optee/optee_os/out/arm-plat-vexpress/export-ta_arm32" }
> ```
>
> In `hello_world-rs/ta/`, running with:
>
> ```
> root@05d55135aefe:~/teaclave_sdk_src/examples/hello_world-rs/ta#
cargo-optee build ta --manifest-path ./Cargo.toml
> Building TA with:
> Arch: Arm
> Debug: false
> Std: false
> TA dev kit dir:
"/opt/teaclave/optee/optee_os/out/arm-plat-vexpress/export-ta_arm32"
> UUID path: "/root/teaclave_sdk_src/examples/hello_world-rs/uuid.txt"
> Building TA in directory: /root/teaclave_sdk_src/examples/hello_world-rs/ta
> Running cargo fmt and clippy...
> ^C
> root@05d55135aefe:~/teaclave_sdk_src/examples/hello_world-rs/ta#
cargo-optee build ta --manifest-path Cargo.toml
> Building TA with:
> Arch: Arm
> Debug: false
> Std: false
> TA dev kit dir:
"/opt/teaclave/optee/optee_os/out/arm-plat-vexpress/export-ta_arm32"
> UUID path: "/root/teaclave_sdk_src/examples/hello_world-rs/uuid.txt"
> Building TA in directory:
> Running cargo fmt and clippy...
> Error: No such file or directory (os error 2)
> ```
>
> The metadata in `Cargo.toml` is parsed correctly (TA dev kit dir, UUID
path are correct). But there is Error with `No such file or directory (os error
2)`
>
> 2. There is diffierent between `mnist-rs` and `hello_world-rs`.
>
> When `ta-dev-kit-dir` is correctly configured in the corresponding
`Cargo.toml`, running the following command under `mnist-rs` produces the
expected output:
>
> ```
> root@05d55135aefe:~/teaclave_sdk_src/examples# cargo-optee build ta \
> > --manifest-path mnist-rs/ta/train/Cargo.toml
> Building TA with:
> Arch: Aarch64
> Debug: false
> Std: false
> TA dev kit dir:
"/opt/teaclave/optee/optee_os/out/arm-plat-vexpress/export-ta_arm64"
> UUID path: "/root/teaclave_sdk_src/examples/mnist-rs/ta/train/uuid.txt"
> Building TA in directory: /root/teaclave_sdk_src/examples/mnist-rs/ta/train
> Running cargo fmt and clippy...
> ^C
> root@05d55135aefe:~/teaclave_sdk_src/examples# cargo-optee build ta
--manifest-path ./mnist-rs/ta/train/Cargo.toml
> Building TA with:
> Arch: Aarch64
> Debug: false
> Std: false
> UUID path: "./mnist-rs/ta/train/../uuid.txt"
> Error: ta-dev-kit-dir is MANDATORY but not configured.
> Please set it via:
> 1. Command line: --ta-dev-kit-dir <path>
> 4. Cargo.toml metadata: [package.metadata.optee.ta] section
>
> Example Cargo.toml:
> [package.metadata.optee.ta]
> ta-dev-kit-dir = { aarch64 =
"/path/to/optee_os/out/arm-plat-vexpress/export-ta_arm64" }
> # arm architecture omitted (defaults to null)
>
> For help with available options, run: cargo-optee build ta --help
> ```
>
> However, the same commands run correctly in hello_world-rs, as shown below:
>
> ```
> root@05d55135aefe:~/teaclave_sdk_src/examples# cargo-optee build ta
--manifest-path hello_world-rs/ta/Cargo.toml
> Building TA with:
> Arch: Aarch64
> Debug: false
> Std: false
> TA dev kit dir:
"/opt/teaclave/optee/optee_os/out/arm-plat-vexpress/export-ta_arm64"
> UUID path: "/root/teaclave_sdk_src/examples/hello_world-rs/uuid.txt"
> Building TA in directory: /root/teaclave_sdk_src/examples/hello_world-rs/ta
> Running cargo fmt and clippy...
> ^C
> root@05d55135aefe:~/teaclave_sdk_src/examples# cargo-optee build ta
--manifest-path ./hello_world-rs/ta/Cargo.toml
> Building TA with:
> Arch: Aarch64
> Debug: false
> Std: false
> TA dev kit dir:
"/opt/teaclave/optee/optee_os/out/arm-plat-vexpress/export-ta_arm64"
> UUID path: "/root/teaclave_sdk_src/examples/hello_world-rs/uuid.txt"
> Building TA in directory: /root/teaclave_sdk_src/examples/hello_world-rs/ta
> Running cargo fmt and clippy...
> ```
>
> Initially, I suspected that this issue was related to how `cargo-optee`
handles paths beginning with `./`. However, since the same `./` usage works
correctly in `hello_world-rs`, this no longer seems to be the case. I am
therefore seeking help from the community to better understand the underlying
cause.
>
> ## 3. TOML Metadata Formatting Issue
> TOML does not support multiline inline tables, so we should change our
`README.md` to:
>
> ```
> ta-dev-kit-dir = { aarch64 = "...", arm = "..." }
> ```
>
> ## 4. Naming Consistency Suggestion
> The project currently uses:
>
> 1. `host` in examples, directory names and `sync_to_emulator`
> 2. `ca` (“client application”) in `cargo-optee`
>
> To improve clarity, it may be beneficial to standardize on a single naming
convention across
>
> This will help reduce confusion for new contributors.
>
> ## 5. Deprecation Suggestion for `switch_config`
> Since `cargo-optee` now provides a unified and structured workflow for
building and running components, the old `switch_config` flow may no longer be
necessary.
>
> Removing it could simplify the overall toolchain and documentation.
>
> ## 6. Test Results Summary
> I tested all examples included in the repository:
>
> * All TAs build successfully with `cargo-optee`
> * All CA/host applications targeting `aarch64` run correctly in QEMUv8
> * Aside from the issues mentioned above, I did not encounter additional
problems
>
> This suggests that the new cargo-optee integration is generally robust
across the example suite. I think it's a good tool.
>
> I would like to ask whether the project would benefit from having a
Makefile under the examples/ directory to manage or build all examples
together. Is this something we might need? Like
[examples/Makefile](https://github.com/apache/teaclave-trustzone-sdk/blob/23a041fd658c99f542e3ba83331784fbe8453819/examples/Makefile)
Hi @asir66 thanks for the effort. Please take my previous comment
(https://github.com/apache/teaclave-trustzone-sdk/pull/245#discussion_r2473250351)to
compare the current `cargo optee` subcommand with existing `cargo`
conventions.
If possible, could you help list all the areas where the current
implementation violates or diverges from standard cargo behavior? Once we have
this list, we can decide whether to fix them within this PR or address them in
a series of follow-up PRs before publishing to crates.io.
A few highlights from my earlier comment for reference:
- Project configuration should stay in each project’s Cargo.toml. Toolchain
configuration (e.g., ta-dev-kit-dir) should be managed by a dedicated
subcommand such as `cargo optee setup`, instead of being mixed into project
config.
- std / no_std selection should be inferred automatically from the active
feature set, consistent with how existing cargo workflows behave.
Thanks in advance.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
