Filesystem API similar to FUSE

[ricmoo]

I've been playing around with v86 (it is awesome and there are so many possibilities; thanks for this project), and have been trying to hack in a custom dynamic filesystem support.

Currently there are is an in-memory filesystem and a server-based one (which accepts a base url and JSON of the files), both of which are somewhat difficult to shoehorn a dynamic file system into.

What I'm interested in is an API similar to FUSE, which can async read/write files at some mount point. So in the v86 configuration, specify a mount point and a fleet of handlers which has keys/operations like open, read, write, readdir, etc.

There is also an example JSON filesystem with a bunch of handlers set, to give an idea of the API.

Curious as to interest from others, and maybe some pointers on where to begin? I don't develop Rust much, but I was wondering if this is something that could be mostly handled in the JavaScript layer. Or perhaps this is simple to already do and I just haven't found the right configuration option.

[progrium]

There are lots of ways to approach this but I'm pretty close to implementing something like this myself, though not directly on v86 but through a guest service. I actually just made a (long) video that talks about how I'm doing it so far, but here is the timecode for the filesystem stuff:
https://youtu.be/q2I37ZtYfm8?t=1732

[ricmoo]

Thanks! I’ll check it out.

I was thinking it would be more of an external API though. Internally to the VM it can continue being a 9p file system, but on the outward facing JavaScript side, it would have a similar API to FUSE.

[SuperMaxusa]

Curious as to interest from others, and maybe some pointers on where to begin?

Here are the bindings for file system: https://github.com/copy/v86/blob/master/lib/filesystem.js
Also you can check out this implementation based on filer.js: #858 (comment)

[ricmoo]

I think the main thing missing to hijack those bindings is something here akin to: if (options.filesystem.file_storage) { file_storage = options.filesystem.file_storage); } which would allow us to inject our own implementation of that class.

Right now internally it uses only our parameters passed to either use Memory or Server storage classes.

[copy]

That sounds like a reasonable request.

I think supporting custom callbacks in the V86 constructor is a good idea, e.g.:

new V86({
    filesystem: {
       getattr: getattr,
       readdir: readdir,
       open: open,
       read: read,
       // ...
    },
    // ...
})

Currently, the internal api of the filesystem is:

ChangeSize(inodeid, req[5])
Check()
CloseInode(inodeid)
CountFreeInodes()
CountUsedInodes()
CreateDirectory(name, inodeid)
CreateFile(name, inodeid)
CreateNode(name, inodeid, major, minor)
CreateSymlink(name, inodeid, symgt)
DescribeLock(req[1], req[2], lock_length, req[4], req[5])
GetInode(idx)
GetLock(inodeid, lock_request)
GetSpace()
GetTotalSize()
Link(inodeid, inodeid, name)
Lock(inodeid, lock_request, flags)
OpenInode(idx, mode)
PrepareCAPs(inodeid)
Read(inodeid, offset, count)
Rename(inodeid, oldname, inodeid, newname)
RoundToDirentry(inodeid, count)
Search(idx, walk[i])
Search(inodeid, name)
Search(inodeid, newname)
Unlink(inodeid, name)
Write(inodeid, offset, count, buffer)