|
| 1 | +# Ocre Runtime platform requirements |
| 2 | + |
| 3 | +Ocre targets a POSIX-like operating system and makes heavy use of the POSIX API. |
| 4 | + |
| 5 | +We specifically use `pthread(3)` for creating the runtime engine threads (which are used by the runtime engine). |
| 6 | + |
| 7 | +Ocre Runtime also exposes a thread-safe API for managing the runtime engine and the lifecycle of the containers. |
| 8 | +This functionality requires `pthread_mutex(3)` and `pthread_cond(3)`. |
| 9 | + |
| 10 | +We explicitly do not make use of `pthread_kill(3)` because it is undefined and unreliable behavior. |
| 11 | + |
| 12 | +This subset of the POSIX API is available in most modern RTOS. |
| 13 | + |
| 14 | +## WAMR |
| 15 | + |
| 16 | +Ocre Runtime by default uses WebAssembly Micro-Runtime (WAMR) for running WASM containers. The integration between WAMR and the underlying platform is done by WAMR and is out of scope of Ocre Runtime. |
| 17 | + |
| 18 | +Check [WAMR porting guide](https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/port_wamr.md) for more information about WAMR platform requirements. |
| 19 | + |
| 20 | +## Container loading |
| 21 | + |
| 22 | +For loading the container into the memory, each platform can provide its own implementation. |
| 23 | + |
| 24 | +The following functions must be available in the platform: |
| 25 | + |
| 26 | +- `void *ocre_load_file(const char *path, size_t *size)`: should make the contents of the file specified in `path` available in a linear memory. This is usually implemented as `mmap(2)` or `open(2)` then `malloc(3)` and `read(2)` |
| 27 | +- `int ocre_unload_file(void *buffer, size_t size)`: should release whatever was acquired by `ocre_load_file`. This is usually implemented as `munmap(2)` or `free(3)` |
| 28 | + |
| 29 | +Check the files in `src/platform/posix/file_alloc_*.c` for reference implementations. |
| 30 | + |
| 31 | +## User memory |
| 32 | + |
| 33 | +Ocre Runtime allows the "application memory" (container memory) to be allocated differently depending on the platform. |
| 34 | + |
| 35 | +The following functions must be available in the platform: |
| 36 | + |
| 37 | +- `void *user_malloc(size_t size)`: should allocate memory of the specified size. This is usually implemented as `malloc(3)` |
| 38 | +- `void user_free(void *p)`: should release the memory allocated by `user_malloc`. This is usually implemented as `free(3)` |
| 39 | +- `void *user_realloc(void *p, size_t size)`: should reallocate the memory allocated by `user_malloc`. This is usually implemented as `realloc(3)` |
| 40 | + |
| 41 | +Check the files in `src/platform/*/memory.c` for reference implementations. |
| 42 | + |
| 43 | +## Logging system |
| 44 | + |
| 45 | +Logging API is inspired by Zephyr's logging API. This requires the following macros to be defined and used by every module that uses logging: |
| 46 | + |
| 47 | +- `LOG_MODULE_REGISTER(module, ...)`: should register the module with the logging system |
| 48 | +- `LOG_MODULE_DECLARE(module, ...)`: should declare the module with the logging system |
| 49 | + |
| 50 | +In Zephyr, these functions behave differently. Ocre just expects any one of these to be called exactly once on each module, defining the name of the module, that will be part of the loggin output. |
| 51 | + |
| 52 | +Also, the following macros or functions should be defined: |
| 53 | + |
| 54 | +- `LOG_ERR(fmt, ...)`: should log an error message |
| 55 | +- `LOG_WRN(fmt, ...)`: should log a warning message |
| 56 | +- `LOG_INF(fmt, ...)`: should log an informational message |
| 57 | +- `LOG_DBG(fmt, ...)`: should log a debug message |
| 58 | + |
| 59 | +These functions are expected to behave like `printf(3)`. |
| 60 | + |
| 61 | +Check Zephyr's [Logging](https://docs.zephyrproject.org/latest/services/logging/index.html) documentation for more information. |
| 62 | + |
| 63 | +## config.h |
| 64 | + |
| 65 | +This file, in the platform is required to define the following macro: |
| 66 | + |
| 67 | +- `CONFIG_OCRE_DEFAULT_WORKING_DIRECTORY`: the default working directory for OCRE. This is usually set to `/var/lib/ocre` on POSIX production systems; `src/ocre/var/lib/ocre` for testing; or `/lfs/ocre` in Zephyr. |
| 68 | + |
| 69 | +Additional configuration options and platform overrides can be defined here as well. |
| 70 | + |
| 71 | +This file usually just sets `CONFIG_OCRE_DEFAULT_WORKING_DIRECTORY` and imports some other file (i.e. `autoconf.h`) so that Ocre can be configured and integrated in another build system. |
| 72 | + |
| 73 | +# Current Platform list: |
| 74 | + |
| 75 | +Ocre Runtime currently supports the following platforms: |
| 76 | + |
| 77 | +- [POSIX](PlatformPosix.md) |
| 78 | +- [Zephyr](PlatformZephyr.md) |
| 79 | + |
| 80 | +Please refer to the platform-specific documentation for more information about their implementation. |
0 commit comments