opendir failed on Zephyr platform

[banana-sun]

OS: Zephyr v3.7.1
WAMR brance: https://github.com/bytecodealliance/wasm-micro-runtime/tree/dev/zephyr_file_socket
Hardware: NUCLEO-H563ZI
Zephyr File System: lfs/test.txt
WAMR FS interaction folder: --dir=/lfs

Runtime implement:

    const char * wasi_dir = "/lfs";

    /* load WASM module */
    wasm_module = wasm_runtime_load(wasm_file_buf, entry.size, error_buf, sizeof(error_buf));

    wasm_runtime_set_wasi_args_ex(wasm_module, &wasi_dir, 1, NULL, 0, NULL, 0, NULL, 0, 0, 1, 2);

    /* instantiate the module */
    wasm_module_inst =
              wasm_runtime_instantiate(wasm_module, CONFIG_APP_STACK_SIZE, CONFIG_APP_HEAP_SIZE, error_buf, sizeof(error_buf));
    wasm_application_execute_main(module_inst, app_argc, app_argv);

Application code:

#include <stdio.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <dirent.h>

void list_dir(const char *path)
{
    struct dirent *entry;
    DIR *dp;

    dp = opendir(path);
    if (dp == NULL) {
        printf("opendir %s\r\n", strerror(errno));
        return;
    }

    while ((entry = readdir(dp))) {
        printf("%s ", entry->d_name);
        if (DT_DIR == entry->d_type) {
            printf("dir\n");
        }
        else if (DT_REG == entry->d_type) {
            printf("file\n");
        }
        else {
            printf("other\n");
        }
    }

    closedir(dp);
}

int
main(int argc, char **argv)
{
    printf("Hello world!\n");

    list_dir("/lfs");
    return 0;
}

Result output:

Hello world!
[00:05:57.244,000] <err> fs: file open error (-21)
opendir

elapsed: 38

Is there any problem with this usage? If the design is like this, please help correct the mistakes. Thank you.

[banana-sun]

I tried again using the latest version of this PR(#4377), but still had this problem.

[lucasAbadFr]

Hello !

This one is actually tricky and may be documented somewhere.

First thing is that we set a mount point for Zephyr File system likely in the embedded runtime application code .
example:

static struct fs_mount_t lfs_storage_mnt = {
    .type = FS_LITTLEFS,
    .fs_data = &storage,
    .storage_dev = (void *)FIXED_PARTITION_ID(storage_partition),
    .mnt_point = "/lfs",
};

Then we willingly choose to pass to the runtime this mount point or path root. This is what you do here:

    const char * wasi_dir = "/lfs";

    /* load WASM module */
    wasm_module = wasm_runtime_load(wasm_file_buf, entry.size, error_buf, sizeof(error_buf));

    wasm_runtime_set_wasi_args_ex(wasm_module, &wasi_dir, 1, NULL, 0, NULL, 0, NULL, 0, 0, 1, 2);

I think that knowing the name of the root does not necessarily means that it is created (not 100% sure)

Then let's look at the call flow that is implemented.

wasm_runtime_init_wasi
           |
           v
  os_open_preopendir
           |
           v
     fs_dir_t_init
           |
           v
       fs_opendir

So the /lfs dir is actually opened.

May be this design could be upgraded but for now it is like that. So the error that you get is expected.

If you want to perform operation on folders, just make a new one with mkdir and it's absolut path.

[banana-sun]

Hi Lucas,

If this is an expected phenomenon, I think I can accept it. At present, I need to confirm whether these problems are designed this way or need to be fixed. This will be very helpful for my subsequent work. Thank you.

[lucasAbadFr]

Clearly, the behavior is implemented this way by design. As for whether it should be considered a problem. I don’t think I’m the right person to make that call.

When I worked on the file system integration, I focused on maintaining a 1:1 behavior (to a resonable limit) between my Zephyr samples and the Linux iwasm implementation, which is currently the most complete and mature target. The goal was to ensure the same WASM module would behave consistently across both platforms.

For more context on the design decisions, including whether a preopened directory should be directly open()'able, or whether this behavior could (or should) evolve. I think @wenyongh or @luminous might be able to offer better insights than me.

Hope this helps !

[lum1n0us]

I believe #4378 and #4399 share the same problem: whether we should use an absolute path or a relative path in wasm code.

If following the original design, wasm code in a sandbox should use a relative path. This is because the wasi capability model is based on preopens, and all paths accessed in wasm code are actually located within those preopens. If I understand correctly, the concept of a sandbox should allow wasm code to move between different sandboxes if we treat those preopens as a major component of a sandbox. There is no need for wasm code to hard-code absolute paths of those preopens.

On the other hand, various configurations might change the type of VFS (like littleFS and fatfs using different absolute paths) and the mount point. To prevent changing wasm code due to Zephyr configuration, using a relative path is a better choice than an absolute path.