Zephyr: fix the product mini compilation issue

[lucasAbadFr]

This pull request present a fix to #4628.

It introduces the following changes:

• Add a new os_nanosleep API.
• Provide a naive but documented Zephyr implementation of os_nanosleep.
• Add documentation for previously introduced os_ APIs in platform_api_extension.h.
• Fix build issues so that the simple-file and simple-http samples compile again.

Note

At first I intended to change os_ioctl return type but didn't in the end.

[lum1n0us]

It is not a standard libc header and leads to a compilation error:

fatal error: libc_errno.h: No such file or directory

[lucasAbadFr]

Yes I know, but it didn't anticipate this error.
In fact I tested building iwasm for Linux (file sample) and no other plateforms (except Zephyr obviously).

From what I see, the issue comes from this CMake logic:

wasm-micro-runtime/core/shared/platform/common/posix/platform_api_posix.cmake

Lines 15 to 22 in 95f506a

	if ((NOT WAMR_BUILD_LIBC_WASI EQUAL 1) AND (NOT WAMR_BUILD_DEBUG_INTERP EQUAL 1))
	list(REMOVE_ITEM source_all
	${PLATFORM_COMMON_POSIX_DIR}/posix_socket.c
	)
	else()
	include (${CMAKE_CURRENT_LIST_DIR}/../libc-util/platform_common_libc_util.cmake)
	set(source_all ${source_all} ${PLATFORM_COMMON_LIBC_UTIL_SOURCE})
	endif()

Now that posix_sleep.c directly include libc_errno.h, we can build with WAMR_BUILD_LIBC_WASI=0 but we still need this helper.

How do we manage this case ? We can:

• Use a case in os_nanosleep on ret for POSIX.
• Change the CMake logic (but I can't cleary indentify the impact)

[lum1n0us]

If it's alright, could I inquire about your experience with: How to set up CI on a Zephyr platform using GitHub Actions? Since there is no board, a simulation is required. So, which is better: nsim or QEMU?

[lucasAbadFr]

I @lum1n0us ! Thank you for the quick review.

Honestly, I don't have any real experiences for setting a CI on the Zephyr platform using Github Actions. But I may share my insights about native sim vs QEMU.

From my understanding about simulation tools:

• native_sim / native_posix: They should be used for "smoke tests" because they build and run very quickly and are executed as a Linux process. But they don't fully replicate the Hardware (I don't think it is really a problem for WAMR). They are great for functional and build validation. IMO we should build and run the samples. Also I identified that the samples won't work as is but we need to modify the WAMR_BUILD_TARGET. We might have a specific CI configuration suited to the runner.

• QEMU: It emulates real hardware, so it is closer to actual devices. From what I see it is already supported in Zephyr see the revelant documentation. It will be an heavier setup and maintenance effort (I think). The builds and runs will mechanicaly be slower.

• Renode: I find this project facinating but didn't really use it yet. It's a simulator that emulates boards and peripherals. The complexity is even heavier than QEMU but it offers detailled hardware modeling. It's probably overkill as zephyr already test there board here.

Also the WAMR project could select a few (embedded) Hardware platforms to support for each of the (RTOS) paltforms supported. It could be aligned with the embedded SIG targeted (hardware) platforms.

But in any case at least trying to compile and run the samples should be pretty simple to put in place, and we should begin by that.