search

genodelabs / genode-world

Collection of community-maintained components for Genode
Other
45 stars 47 forks source link

fuse_fs: compile errors with current Genode staging branch #199

Open cproc opened 4 years ago

cproc commented 4 years ago

When building 'make server/fuse_fs' with the current Genode staging branch, the following errors occur:

    COMPILE  fuse_fs_main.o                                                                                                                                                                                                         [8/1815]
In file included from /.../repos/world/src/server/fuse_fs/exfat/../directory.h:30,
                 from /.../repos/world/src/server/fuse_fs/exfat/../fuse_fs_main.cc:27:
/.../repos/world/src/server/fuse_fs/exfat/../file.h: In member function ‘virtual File_system::Status Fuse_fs::File::status()’:
/.../repos/world/src/server/fuse_fs/exfat/../file.h:124:11: error: ‘struct File_system::Status’ has no member named ‘mode’; did you mean ‘inode’?
    status.mode = File_system::Status::MODE_FILE;
           ^~~~
           inode
/.../repos/world/src/server/fuse_fs/exfat/../file.h:124:39: error: ‘MODE_FILE’ is not a member of ‘File_system::Status’
    status.mode = File_system::Status::MODE_FILE;
                                       ^~~~~~~~~
In file included from /.../repos/world/src/server/fuse_fs/exfat/../directory.h:34,
                 from /.../repos/world/src/server/fuse_fs/exfat/../fuse_fs_main.cc:27:
/.../repos/world/src/server/fuse_fs/exfat/../symlink.h: In member function ‘virtual File_system::Status Fuse_fs::Symlink::status()’:
/.../repos/world/src/server/fuse_fs/exfat/../symlink.h:65:11: error: ‘struct File_system::Status’ has no member named ‘mode’; did you mean ‘inode’?
    status.mode = File_system::Status::MODE_FILE;
           ^~~~
           inode
/.../repos/world/src/server/fuse_fs/exfat/../symlink.h:65:39: error: ‘MODE_FILE’ is not a member of ‘File_system::Status’
    status.mode = File_system::Status::MODE_FILE;
                                       ^~~~~~~~~
In file included from /.../repos/world/src/server/fuse_fs/exfat/../fuse_fs_main.cc:27:
/.../repos/world/src/server/fuse_fs/exfat/../directory.h: In member function ‘virtual File_system::Status Fuse_fs::Directory::status()’:
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:206:11: error: ‘struct File_system::Status’ has no member named ‘mode’; did you mean ‘inode’?
    status.mode  = File_system::Status::MODE_DIRECTORY;
           ^~~~
           inode
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:206:39: error: ‘MODE_DIRECTORY’ is not a member of ‘File_system::Status’
    status.mode  = File_system::Status::MODE_DIRECTORY;
                                       ^~~~~~~~~~~~~~
/.../repos/world/src/server/fuse_fs/exfat/../directory.h: In member function ‘virtual Genode::size_t Fuse_fs::Directory::read(char*, Genode::size_t, File_system::seek_off_t)’:
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:253:39: error: ‘TYPE_FILE’ is not a member of ‘File_system::Directory_entry’
    case DT_REG: e->type = Directory_entry::TYPE_FILE;      break;
                                       ^~~~~~~~~
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:254:39: error: ‘TYPE_DIRECTORY’ is not a member of ‘File_system::Directory_entry’
    case DT_DIR: e->type = Directory_entry::TYPE_DIRECTORY; break;
                                       ^~~~~~~~~~~~~~
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:255:40: error: ‘TYPE_SYMLINK’ is not a member of ‘File_system::Directory_entry’
    case DT_LNK: e->type = Directory_entry::TYPE_SYMLINK;   break;
                                        ^~~~~~~~~~~~
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:270:41: error: ‘TYPE_FILE’ is not a member of ‘File_system::Directory_entry’
      case DT_REG: e->type = Directory_entry::TYPE_FILE;      break;
                                         ^~~~~~~~~
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:271:41: error: ‘TYPE_DIRECTORY’ is not a member of ‘File_system::Directory_entry’
      case DT_DIR: e->type = Directory_entry::TYPE_DIRECTORY; break;
                                         ^~~~~~~~~~~~~~
/.../repos/world/src/server/fuse_fs/exfat/../directory.h:281:15: error: cannot convert ‘File_system::Directory_entry::Name’ to ‘char*’
    strncpy(e->name, dent->d_name, sizeof(e->name));
            ~~~^~~~
In file included from /.../repos/base/include/base/capability.h:19,
                 from /.../repos/base/include/base/ram_allocator.h:17,
                 from /.../repos/base/include/base/heap.h:19,
                 from /.../repos/world/src/server/fuse_fs/exfat/../fuse_fs_main.cc:15:
/.../repos/base/include/util/string.h:182:29: note:   initializing argument 1 of ‘char* Genode::strncpy(char*, const char*, Genode::size_t)’
  inline char *strncpy(char *dst, const char *src, size_t size)
                       ~~~~~~^~~
/.../repos/world/src/server/fuse_fs/exfat/../fuse_fs_main.cc: In member function ‘void Fuse_fs::Session_component::_process_packet_op(File_system::Packet_descriptor&, Fuse_fs::Session_component:
:Open_node&)’:
/.../repos/world/src/server/fuse_fs/exfat/../fuse_fs_main.cc:77:11: warning: enumeration value ‘WRITE_TIMESTAMP’ not handled in switch [-Wswitch]
    switch (packet.operation()) {
           ^
/.../repos/base/mk/generic.mk:56: recipe for target 'fuse_fs_main.o' failed
ttcoder commented 2 years ago

Finally got around to working on FUSe, starting with this ticket. (didn't look at #174 as the libc part is deprecated I think).

Basically, the attached patch...

ticket_199.diff.txt

...seems to get server/fuse_fs back in compiling shape, re. the compiling errors outlined above.

Though the resulting binary still fails at runtime:

[init -> fs] libc_fuse_ntfs-3g: try to mount /dev/blkdev...
[init -> fs] Error: libc suspend() called from non-user context (0x10f5edba) - aborting
[init] child "fs" exited with exit value 1

That is as per ticket #193, so it probably still needs my "patch", plus the transition/conversion to a VFS plug-in. I'll get started on that over the next few weeks. Will probably apply my "patch" first and check that tests pass OK, and only then work on the transition to plug-in, to have a solid foundation to work on.

I'll do my best to follow the Genode Coding style.

ttcoder commented 2 years ago

So I extended the "patch", and together with the fcntl() tweak and this bigger patch applied...

ticket_199_diff_v2.txt

......the legacy fuse-ntfs server completes the tests in a few mins and passes except for two exceptions :

1) the "readv(fd, iov, 2)" test has to be remed out, fails in packet processing for some reason:

[init -> test-libc_vfs] calling readv(fd, iov, 2)
[init -> test-libc_vfs] Error: packet operation=0 failed
[init -> test-libc_vfs] readv(fd, iov, 2) failed, count=-1, errno=5

2) when tearing down the tests and syncing/unmounting, the server outputs an error:

[init -> fs] libc_fuse_ntfs-3g: sync file system...
[init -> test-libc_vfs] finished round 3
[init -> test-libc_vfs] test finished
[init] child "test-libc_vfs" exited with exit value 0
[init -> fs] libc_fuse_ntfs-3g: sync file system...
[init -> fs] Error: ID space not empty at destruction time

I don't use readv() in my TTS code, but if the rest works ok, that looks good for my future plans.

Now heading to ticket #193

cnuke commented 2 years ago

The following commits address this issue:

The last ones fix bugs in the fuse_fs implementation after which the exfat and ext2 tests now succeed.

(Some of the compilation errors were already fixed by @ttcoder but for better or worse I only noticed the when looking up the number of this issue.)

nfeske commented 2 years ago

Thanks @cnuke. I merged your commit series to staging.

cnuke commented 2 years ago

@ttcoder I saw that you circumvented the problem with ntfs-3g (opening of / fails). I would like to post-pone applying that as I would like to check if the FUSE operations we use for directory management rely on the struct fuse_file_info being properly initalized.

ttcoder commented 2 years ago

I saw that you circumvented the problem with ntfs-3g (opening of / fails).

You mean the ENOENT bit ? Indeed there's probably a better way to fix that ; if we find which part of ntfs-3g returns that spurious code, we can patch it there directly (until there's a new version of the ntfs-3g library shipping with bugfixes), and keep the ENOENT handling intact.

Edit -- Oh I just understood what you mean, the problem might be due to a non-initialized struct, not to incorrect code in ntfs-3g, gotcha. FWIW, I reviewed your commits and they LGTM!