@DorianZheng Please have a look.
I tried to add the FFI tests (boxlite-ffi) to the GitHub Actions workflow, but the job failed.

Reason:
The GitHub runners don’t have the required native dependencies (e.g., libkrun, and KVM support) needed to link and/or run these tests.

What I tried:
I attempted to use BOXLITE_DEPS_STUB=1 to mock the underlying native libraries and bypass the native linking requirements. However, this
approach turned out to be complex and unstable in the CI environment (getting stub libraries/symbols wired correctly across crates).

Question:
Is running the FFI unit tests in CI a blocking requirement for this PR? If so, we’ll likely need a more robust mocking strategy for the
core runtime components. For now, I verified the FFI bindings locally.

@qidi1 Thank you very much

@DorianZheng Please have a look. I tried to add the FFI tests (boxlite-ffi) to the GitHub Actions workflow, but the job failed.

Reason: The GitHub runners don’t have the required native dependencies (e.g., libkrun, and KVM support) needed to link and/or run these tests.

What I tried: I attempted to use BOXLITE_DEPS_STUB=1 to mock the underlying native libraries and bypass the native linking requirements. However, this approach turned out to be complex and unstable in the CI environment (getting stub libraries/symbols wired correctly across crates).

Question: Is running the FFI unit tests in CI a blocking requirement for this PR? If so, we’ll likely need a more robust mocking strategy for the core runtime components. For now, I verified the FFI bindings locally.

Hi @qidi1. I will review and merge this PR after review, and it's better to have a Mock method to run the UT in a separate PR. What do you think?

Regenerate C header when shared FFI sources change — /Users/zhengzhiquan/Workspace/boxlite/sdks/c/build.rs:24-25

After this refactor, cbindgen pulls public types from boxlite-ffi (parse_deps = true), but the build script only reruns when sdks/c/src or cbindgen.toml change. If only sdks/boxlite-ffi changes, cargo build -p boxlite-c can leave sdks/c/include/boxlite.h stale, causing the published C header to drift from the actual exported FFI surface.

@qidi1 Thank you very much

@DorianZheng Please have a look. I tried to add the FFI tests (boxlite-ffi) to the GitHub Actions workflow, but the job failed.
Reason: The GitHub runners don’t have the required native dependencies (e.g., libkrun, and KVM support) needed to link and/or run these tests.
What I tried: I attempted to use BOXLITE_DEPS_STUB=1 to mock the underlying native libraries and bypass the native linking requirements. However, this approach turned out to be complex and unstable in the CI environment (getting stub libraries/symbols wired correctly across crates).
Question: Is running the FFI unit tests in CI a blocking requirement for this PR? If so, we’ll likely need a more robust mocking strategy for the core runtime components. For now, I verified the FFI bindings locally.

Hi @qidi1. I will review and merge this PR after review, and it's better to have a Mock method to run the UT in a separate PR. What do you think?

I will add in other PR

@qidi1 Thank you very much

@DorianZheng Please have a look. I tried to add the FFI tests (boxlite-ffi) to the GitHub Actions workflow, but the job failed.
Reason: The GitHub runners don’t have the required native dependencies (e.g., libkrun, and KVM support) needed to link and/or run these tests.
What I tried: I attempted to use BOXLITE_DEPS_STUB=1 to mock the underlying native libraries and bypass the native linking requirements. However, this approach turned out to be complex and unstable in the CI environment (getting stub libraries/symbols wired correctly across crates).
Question: Is running the FFI unit tests in CI a blocking requirement for this PR? If so, we’ll likely need a more robust mocking strategy for the core runtime components. For now, I verified the FFI bindings locally.

Hi @qidi1. I will review and merge this PR after review, and it's better to have a Mock method to run the UT in a separate PR. What do you think?

I will add in other PR

Great! I will just merge this PR and please file another PR for mock for UT