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

fs: Filesystem module (WIP) #2474

Closed
wants to merge 16 commits into from
Closed

fs: Filesystem module (WIP) #2474

wants to merge 16 commits into from

Conversation

x3ro
Copy link
Contributor

@x3ro x3ro commented Feb 19, 2015

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

  • @authmillenon's implementation proposal inspired by FUSE
  • errno should not be used since its no thread-safe/reentrant. The functions should just return negated error codes instead.
  • @Kijewski said that "we should not target to implement all these functions. We don't want to become a less well-tested Linux."
  • Filesystems should be added as packages
    • CFS (used by Contiki, BSD license)
    • Coffee, also by Contiki, which is meant to be used with Flash memory
    • FatFS (custom license compatible to BSD)
      • @gebart: "FAT would be useful for SD card storage, which provide internal wear levelling, but it would probably wear out simpler flash chips too quickly to be useful on those."
  • CFS is closely integrated into the Contiki repo. How do we add it as a package?
    • @gebart: "Can we add it as a pkg with some script to fetch a git revision and strip everything except the CFS pieces?"
    • @OlegHahm: "Maybe we should reach out to the Contiki people and see if we can maintain CFS as an external library together on the long run."
  • File descriptors

@authmillenon: Some thought on file descriptors I had I'd like to share: Maybe any value of kernel_pid_t with > MAXTHREADS is the best solution, since in POSIX even pthreads have fds and this way we can just have them be the actual PID, while anything else is uniquely identified. This way we have a unique numbering scheme and have the POSIX wrapper for pthreads and file operations as easy as possible. Sockets would also grab from the same pool then (and we have the option to run every socket in it's own light-weight thread (if we'll have something like that) in the future, maybe).

ToDo

  • Determine which FS operations RIOT needs and which one FS implementations require
  • Figure out what state the SDHC support on the MSB-A2 is in. Hasn't been tested in a while according to @OlegHahm
  • Verify that the code to be used has is license-compatible (possible with the help of http://wiki.osdev.org/Licensing). We should be allowed to pull BSD sources into LPGL.
  • Figure out how to integrate CFS/Coffee
  • Fully understand @authmillenon's thoughts on file descriptors
  • Should setting errno be completely removed from the code?

@OlegHahm OlegHahm added State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Feb 19, 2015
* @return ENOENT, TODO
* @return EINVAL, TODO
*/
int fs_unmount(const char *mount_point, int device);
Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Member

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.

@benpicco
Copy link
Contributor

benpicco commented Mar 5, 2015

spiffs is another embedded flash file system with wear levelling you might consider.

@OlegHahm OlegHahm modified the milestones: Release 2015.12, Release 2016.03 Dec 8, 2015
@OlegHahm
Copy link
Member

@x3ro, what's the state?

@x3ro
Copy link
Contributor Author

x3ro commented Feb 26, 2016

@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.

@OlegHahm OlegHahm added the State: archived State: The PR has been archived for possible future re-adaptation label Feb 26, 2016
@OlegHahm
Copy link
Member

Close as memo then.

@OlegHahm OlegHahm closed this Feb 26, 2016
@kYc0o kYc0o mentioned this pull request Mar 23, 2016
@OlegHahm
Copy link
Member

Maybe we can use https://github.com/yarrick/pingfs instead? Thanks, @mfrey for the pointer. ;-)

@x3ro
Copy link
Contributor Author

x3ro commented Apr 13, 2016

👍

@miri64
Copy link
Member

miri64 commented Apr 13, 2016

a specific file system implementation instead of a general API to a file system... sounds legit :P

@kYc0o
Copy link
Contributor

kYc0o commented Apr 13, 2016

Do you think that for large file is it useful? IMO more data -> more transmissions (ping) -> more power...

@miri64
Copy link
Member

miri64 commented Apr 13, 2016

@kYc0o I think that is more of a fun project, than something that is to be considered for production context ;-)

@kYc0o
Copy link
Contributor

kYc0o commented Apr 13, 2016

Yeah... I didn't feel the sarcasm on the comments :-P

@jnohlgard
Copy link
Member

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.

@jnohlgard jnohlgard mentioned this pull request Jul 8, 2016
55 tasks
@jnohlgard
Copy link
Member

See #5616 for a new attempt to take on this old topic

@jnohlgard jnohlgard added the Area: fs Area: File systems label Feb 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: fs Area: File systems State: archived State: The PR has been archived for possible future re-adaptation State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants