FUSE suppport #54

New Issue

yannickulrich · 2023-02-26T13:32:43Z

yannickulrich commented

2023-02-26 13:32:43 +00:00

I've started looking into exposing the watches' file system over FUSE. This way, we can access files on the watch without having to go through itctl or developing 3rd party tools. If and when my gallery app gets merged, this would allow us to just use vim or another text editor to put files on the watch.

I have started playing this in my fork. Once it's a bit more mature and better tested, I can open a pull request here. At the moment I'm just curious if there's interest in having this and what feature we should have.

read/write access to the file system
read access to momentary sensor data
live access to sensor data (i.e. WatchMotion rather than Motion)
configuration of mount point

What do you think of this?

I've started looking into exposing the watches' file system over FUSE. This way, we can access files on the watch without having to go through `itctl` or developing 3rd party tools. If and when my [gallery app](https://github.com/InfiniTimeOrg/InfiniTime/pull/1384) gets merged, this would allow us to just use vim or another text editor to put files on the watch. I have started playing this in [my fork](https://gitlab.com/yannickulrich/itd). Once it's a bit more mature and better tested, I can open a pull request here. At the moment I'm just curious if there's interest in having this and what feature we should have. - [x] read/write access to the file system - [x] read access to momentary sensor data - [ ] live access to sensor data (i.e. `WatchMotion` rather than `Motion`) - [ ] configuration of mount point What do you think of this?

Elara6331 commented

2023-02-26 17:20:17 +00:00

Assuming the fuse library you're using doesn't link libfuse, I think this is a great idea. I don't think it does, but it doesn't explicitly state that anywhere. The easiest way to check is to try cross-compiling it. If you do GOARCH=riscv64 go build in your fork, does it work or do you get an error?

If it does link libfuse, then I'd say put it in a separate project that communicates with ITD rather than ITD itself, because ITD contains no C dependencies and is pure Go, allowing for easy cross-compilation, static executables, etc. Adding libfuse would make lots of things a lot more complicated.

Other than that, it's definitely a great idea. Thanks.

Assuming the fuse library you're using doesn't link `libfuse`, I think this is a great idea. I don't think it does, but it doesn't explicitly state that anywhere. The easiest way to check is to try cross-compiling it. If you do `GOARCH=riscv64 go build` in your fork, does it work or do you get an error? If it does link `libfuse`, then I'd say put it in a separate project that communicates with ITD rather than ITD itself, because ITD contains no C dependencies and is pure Go, allowing for easy cross-compilation, static executables, etc. Adding `libfuse` would make lots of things a lot more complicated. Other than that, it's definitely a great idea. Thanks.

yannickulrich commented

2023-02-26 19:20:15 +00:00

GOARCH=riscv64 go build runs through without fault and the executable seems to run on my ARM system. Thanks for pointing this out and including the command

`GOARCH=riscv64 go build` runs through without fault and the executable seems to run on my ARM system. Thanks for pointing this out and including the command

Elara6331 commented

2023-02-27 23:17:23 +00:00

I've had a closer look at your fork. It looks good. The only thing I'd say should be changed is that the fuse.go file should only contain the startFuse function (which should be called startFUSE according to Go naming conventions). Everything else should be in a separate package inside internal, something like internal/fusefs. I'd also say you should split the converters into a converters.go file inside that new package to improve readability a bit.

I've had a closer look at your fork. It looks good. The only thing I'd say should be changed is that the `fuse.go` file should only contain the `startFuse` function (which should be called `startFUSE` according to Go naming conventions). Everything else should be in a separate package inside `internal`, something like `internal/fusefs`. I'd also say you should split the converters into a `converters.go` file inside that new package to improve readability a bit.

yannickulrich commented

2023-03-01 16:49:38 +00:00

Thanks for the review, I've done this now and opened a pull request !55. Let me know if you want me to change other things as well