Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fuse_fs: compile errors with current Genode staging branch #199

Open
cproc opened this issue Dec 17, 2019 · 6 comments
Open

fuse_fs: compile errors with current Genode staging branch #199

cproc opened this issue Dec 17, 2019 · 6 comments

Comments

@cproc
Copy link
Member

cproc commented Dec 17, 2019

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
Copy link

ttcoder commented Nov 9, 2021

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
Copy link

ttcoder commented Nov 15, 2021

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
  1. 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 added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
Libc plugins are superceeded by VFS plugins and on their way out for
some time now.

Issue genodelabs#199.
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
cnuke added a commit to cnuke/genode-world that referenced this issue Dec 17, 2021
@cnuke
Copy link
Member

cnuke commented Dec 17, 2021

The following commits address this issue:

  • 84b50e2 - Remove 'libc_fuse'
  • 7eb2937 - fuse-ext2: fix compilation errors
  • 4c5142e - libexfat: fix compilation errors
  • e5108bf - libfuse: fix compilation error
  • 767a6d7 - fuse_fs: fix compilation errors
  • 319e438 - Fix FUSE file system server run scripts
  • d02770c - fuse_fs: fix read returning 0 bytes
  • a36cf9a - fuse_fs: fix order of rename arguments
  • 1e4492c - fuse_fs: fix deleting directories

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 pushed a commit that referenced this issue Dec 17, 2021
Libc plugins are superceeded by VFS plugins and on their way out for
some time now.

Issue #199.
nfeske pushed a commit that referenced this issue Dec 17, 2021
nfeske pushed a commit that referenced this issue Dec 17, 2021
nfeske pushed a commit that referenced this issue Dec 17, 2021
nfeske pushed a commit that referenced this issue Dec 17, 2021
nfeske pushed a commit that referenced this issue Dec 17, 2021
nfeske pushed a commit that referenced this issue Dec 17, 2021
nfeske pushed a commit that referenced this issue Dec 17, 2021
nfeske pushed a commit that referenced this issue Dec 17, 2021
@nfeske
Copy link
Member

nfeske commented Dec 17, 2021

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

@cnuke
Copy link
Member

cnuke commented Dec 17, 2021

@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
Copy link

ttcoder commented Dec 17, 2021

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants