You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The virtual file system should support arbitrary file system mounting, similar to the structure used on POSIX systems. User code should be able to provide a custom file system driver for a mount point, similar to the FUSE API present in UNIX-like systems. The custom file system would provide support for reading, writing, creating, deleting, and moving files and directories. Additionally, this functionality should be exposed idiomatically in both C and C++.
Example use cases:
Representing custom electronics devices as socket files
Representing data from a co-processor board as a remote file system
Providing access to a directory on the programmer's computer as a remote file system
Embed resource files (such as PNGs) in a compiled program, accessible via virtual filesystem.
Note that under the current architecture, any of these use cases must be implemented in the kernel itself (which limits what end-users are able to implement on their own, which is especially significant for the custom electronics/co-processor cases), and must be hard-coded to a directory known at kernel compile time (which makes it impossible to have multiple of the same type of file system mounted). The current implementation is also rather fragile in terms of parsing file paths.
In addition, the current API does not support some standard filesystem operations such as deleting files, renaming files, or any directory-related operations. Support for these should be made possible for drivers created using this system.
Proposed outline of C API:
Structure representing a filesystem driver (essentially what fs_driver is right now, though with a more user-friendly API).
Structure representing a mount, containing a mount path, the pointer to the driver, and a data pointer. (Optional: add a short description field as well).
Mount function, taking a pointer to a mount structure (lifetime managed by the user).
Unmount function, taking a pointer to a mount structure.
Lookup function taking a filepath and returning the pointer to the mount structure providing it (i.e. pros_vfs_lookup("/ser/sout") returns the pointer to the mount struct for the /ser filesystem).
Standard library (newlib) stubs reimplemented in terms of the internal data structures of the VFS subsystem.
Proposed outline of C++ API:
Abstract class for a filesystem instance, with pure virtuals corresponding to the function pointers in the C structure (though with C++-ified APIs).
Constructor takes a mount path (and description if we decide to do that), and mounts the filesystem.
Destructor unmounts the filesystem.
Operations may fail by throwing C++ exceptions; these must be caught and translated to internal VFS errors.
Lookup function maps filepath to a reference to the filesystem instance, with documentation warning users about potential dangling reference issues.
Actual Behavior:
Currently, only the built-in serial, smart port and MicroSD file systems are supported, and their mount points are hard-coded.
System information:
Platform: Any
PROS Kernel Version: Any
The text was updated successfully, but these errors were encountered:
HotelCalifornia
added
the
rfc
This describes a feature, enhancement, or optimization in broad terms and should be discussed
label
Oct 18, 2019
HotelCalifornia
changed the title
RFC: More complete VFS implementation
More complete VFS implementation
Oct 18, 2019
Expected Behavior:
The virtual file system should support arbitrary file system mounting, similar to the structure used on POSIX systems. User code should be able to provide a custom file system driver for a mount point, similar to the FUSE API present in UNIX-like systems. The custom file system would provide support for reading, writing, creating, deleting, and moving files and directories. Additionally, this functionality should be exposed idiomatically in both C and C++.
Example use cases:
Note that under the current architecture, any of these use cases must be implemented in the kernel itself (which limits what end-users are able to implement on their own, which is especially significant for the custom electronics/co-processor cases), and must be hard-coded to a directory known at kernel compile time (which makes it impossible to have multiple of the same type of file system mounted). The current implementation is also rather fragile in terms of parsing file paths.
In addition, the current API does not support some standard filesystem operations such as deleting files, renaming files, or any directory-related operations. Support for these should be made possible for drivers created using this system.
Proposed outline of C API:
fs_driver
is right now, though with a more user-friendly API).pros_vfs_lookup("/ser/sout")
returns the pointer to the mount struct for the/ser
filesystem).Proposed outline of C++ API:
Actual Behavior:
Currently, only the built-in serial, smart port and MicroSD file systems are supported, and their mount points are hard-coded.
System information:
Platform: Any
PROS Kernel Version: Any
The text was updated successfully, but these errors were encountered: