[HELP] FFI compatiblity issues

[no1wudi]

Description

Backgound

I'm porting Rust libstd to NuttX, and I've run into a problem with FFI.

Please check the early work in progress: https://github.com/apache/nuttx-apps/pull/2487

For Rust, the libstd is split into two parts: libcore and libstd. The libcore is a minimal runtime that can be used on bare metal systems, and it doesn't depend on any OS-specific functionality. The libstd, on the other hand, depends on the OS-specific functionality, such as threading, networking, etc.

libstd uses libc for FFI, and them usually shipped as static libraray. And I've run into a problem with that.

Problem

NuttX is highly configurable, the good part of it is that you can disable anything you don't need, but the bad part is that you can't assume anything about the system. For example, the size of complex types like struct timespec can be different:

https://github.com/apache/nuttx/blob/f7adb52c8bafd3a242af4c80e27b64c534553ae5/include/time.h#L113-L117

The time_t type can be 32 or 64 bits, and the struct timespec can be 8 or 16 bytes. This is a problem for Rust, because it's hard to catch this at compile time.

And for libc, there are many complex types will be used in both Rust side and C side, for current implmentation of libc crate, they defiend all of these types again with #[repr(C)], which means that they have the same layout as in C:

https://github.com/no1wudi/libc/blob/b395ec66982ae160dba1d7061c51311f32052633/src/unix/nuttx/mod.rs#L32-L56

Maybe for other OS, the data definitons are stable enough, but for NuttX, it's not.

For example, these data types are used in libc crate:

https://github.com/apache/nuttx/blob/f7adb52c8bafd3a242af4c80e27b64c534553ae5/include/pthread.h#L221-L243

It's hard to map CONFIG_SCHED_SPORADIC and CONFIG_SMP and mores one by one in Rust side, espcially in a cross-compiling environment.

And full list of data types used in libc crate can be found here: https://github.com/no1wudi/libc/blob/libc-0.2/src/unix/nuttx/mod.rs

Possible Solutions

1. Reserving space in Rust side for all possible data types

This is the most simple solution, but it's not very elegant. Many strucutres can be used as opaue data blobs in Rust side, they don't need to be defined excatly same as in C side, just keepping the sizse of them is enough, for example:

https://github.com/no1wudi/libc/blob/b395ec66982ae160dba1d7061c51311f32052633/src/unix/nuttx/mod.rs#L79-L81

The drawback of this solution:

1. Waste memory space, especially for embedded systems.
2. Hard to maintain, if the data type is changed in C side, and exceeeding the reserved size, it will cause undefined behavior.

2. Mapping all possible conigurations in Rust side

The drawback of this solution:

1. It's hard to maintain the configs in both Rust and NuttX side, or other lanuages in the future.
2. The libstd and libcore must be build from source code each time.

3. Isolate the exported data types from NuttX

Do not use the libc data typs directly in NuttX intenral if any funtionality is conigurable, instead, define a new data type for it.

The drwa back of this solution:

1. It's a larage work to change all the exported data types from NuttX.

4. Let Rust runtime only avaliable with specific configurations

For example, add a special config like CONFIG_RUST_RUNTIME in NuttX, and let it depenends on all the configurations that Rust runtime needs and match the data types with libc crate:

config RUST_RUNTIME
    bool "Enable Rust Runtime"
    depends on !ARCH_FPU
    depends on SYSTEM_TIME64
    depends on ANYOTHER_ESSENTIAL_CONFIGS

Discussion

I prefer the solution 4, but it's less flexible if you do not want to use full feaure of Rust libstd.

Any sugestions are welcome!

Verification

• [X] I have verified before submitting the report.