-
Notifications
You must be signed in to change notification settings - Fork 2k
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
fs: Filesystem module (WIP) #2474
Conversation
This seems to be stemming from miri64/RIOT@6f9b03e569ba where an initial SCFS module is/was being developed.
Otherwise it will be undefined for the rest of the function
Perhaps @authmillenon can help? :)
This will be a FS that accesses the filesystem of the underlying host in RIOTs native mode
* @return ENOENT, TODO | ||
* @return EINVAL, TODO | ||
*/ | ||
int fs_unmount(const char *mount_point, int device); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does fs_unmount
actually need both mount_point
and device
? Wouldn't just the mount_point suffice, as the device is contained in fs_table_t
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you mount a device on multiple locations you'll need to know which one to unmount. I do not know if the implementation is supposed to support that use case, however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess my original idea was, that you can choose if you want to select the device or the mount point as your identifier for unmounting (similar to the umount
command). But yeah, I guess you can implement this in other ways and don't have to hardcode it into the API.
spiffs is another embedded flash file system with wear levelling you might consider. |
9f184dd
to
45554bf
Compare
@x3ro, what's the state? |
@OlegHahm This can be closed, as the FS module envisioned here won't be implemented (at least by me :D), as discussed on the mailing list. I'm currently finishing up my thesis (due end of march) and will work on a mergeable pull request afterwards. |
Close as memo then. |
Maybe we can use https://github.com/yarrick/pingfs instead? Thanks, @mfrey for the pointer. ;-) |
👍 |
a specific file system implementation instead of a general API to a file system... sounds legit :P |
Do you think that for large file is it useful? IMO more data -> more transmissions (ping) -> more power... |
@kYc0o I think that is more of a fun project, than something that is to be considered for production context ;-) |
Yeah... I didn't feel the sarcasm on the comments :-P |
Just leaving a message here to notify that I am currently working on a simple VFS layer with POSIX semantics. I'll open a WIP PR when there is anything to show. |
See #5616 for a new attempt to take on this old topic |
Filesystem module
This is a continuation of @authmillenon's PR #1265, which she agreed to delegate to me since it seems like I'll be working on the topic of FS for RIOT in my masters thesis :)
Summary of the discussion so far
errno
should not be used since its no thread-safe/reentrant. The functions should just return negated error codes instead.ToDo
errno
be completely removed from the code?