From 6e807fd62dafd4715c29510082e0438f3a9b9b64 Mon Sep 17 00:00:00 2001 From: yyc12345 Date: Tue, 18 Aug 2026 07:59:12 +0800 Subject: [PATCH] doc: update README and DEVNOTES --- DEVNOTES.md | 1 + README.md | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/DEVNOTES.md b/DEVNOTES.md index 83eab55..f0b4349 100644 --- a/DEVNOTES.md +++ b/DEVNOTES.md @@ -5,6 +5,7 @@ ### Bump OMRF Version Up - Change the version declared in `Cargo.toml`. +- Change the version of dependency example in FFI design manual `rust-side/misc.md` ### Bump OMRF Packer Version Up diff --git a/README.md b/README.md index 22a10bc..55880da 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ So we develop it for our special requirements. ### Not `cbindgen` `cbindgen` is a good tool but it only simply resolve only one Rust source file. -It can't handle `use` syntax and means that we need put all things into single file. +It can't handle `use` syntax. This means that we need put all things into single file. For a large-scale FFI interface, this behavior is unacceptable. ### Not `Diplomat` @@ -25,7 +25,7 @@ Mozilla developed `Diplomat` is another great tool but it still doesn't fit our `Diplomat` prefers integrating Rust in workflow rather than distributing Rust built artifacts. Although `Diplomat` generated C/C++ header files can correctly process module relation and `use` syntax, it generated header files involve too much hacks and memory layout assumption based on target triple. -This behavior causes that it generated header files only works on build machine and can not be distributed. +This behavior causes that it generated header files only works on target machine and can not be distributed. It violates our requirements that we want our developed Rust projects can be distributed like a normal CMake project. Sarasas Chip Workshop developed Rust projects has no requirement that exposing complex structs like