ramfs as an example/benchmark

[nbdd0121]

Tmpfs/ramfs sounds like a simple enough example that can both be used as a show case and a benchmark.

[foxhlchen]

I was actually thinking about writing a debugfs in rust.
@ojeda sent me this https://gitlab.cs.washington.edu/sm237/bentofs and said Samantha Miller will be joining Zulip.
I don't know if @ojeda has a plan already??
Or maybe we can make a plan here?

[nbdd0121]

debugfs is good as well; ramfs is much simpler though :) ramfs is 641 LOC in C and debugfs in 2048 LOC.

[foxhlchen]

IIUC, Tmpfs/ramfs is bound with the driver model and device tree. it's implemented under mm/
debugfs is a normal fs.

[nbdd0121]

tmpfs is and ramfs is just a normal fs. I'll drop tmpfs from the title.

[foxhlchen]

But whatsoever, the idea is to implement a simple in-memory filesystem. Both of them are ok. :D

[ojeda]

No specific plan from me, so please feel free to work on an example filesystem and/or benchmark!

[foxhlchen]

Great!! So @nbdd0121, what do you think? Will you work on this?? I'm interested in this part, would you prefer to work together? Or you have other plans? Any thoughts?? 🤔

[nbdd0121]

If you want to work on it, go for it! I'll be happy to offer help or advices whenever you need them ;)

[foxhlchen]

If you want to work on it, go for it! I'll be happy to offer help or advices whenever you need them ;)

Wow! Thank you!!

[smiller123]

Hello I just saw this and see that I'm mentioned earlier in the conversation! Yes, I've written a simple in-memory FS in Rust in the kernel and a more complicated Xv6 based file system. I was writing all my own abstractions around kernel functions and have a C component to the FSes, so I don't know how well it'll match with this work, but I'm happy to work with you on it and share everything I've done so far.

[niklasmohrin]

Hey everyone! First things first, thank you all for your work on the Linux kernel :)

We, that is @bewee @TheGrayStone @taminob and me, have been working on implementing a file system using the kernel crate for a couple of months now. In fact, we have a running implementation of ramfs too, with a lot of the needed Rust abstractions. We would be very excited to work with all of you.

Our work is part of a lecture at university and we would have to come to an agreement with the lecturer before being able to take contributions to our branch, in case that is in anyone's interest. These constraints are of course lifted when the grading process is done. (Due to the same reasons, we originally wanted to wait until the end of the semester to contact you, but after we saw this issue, we felt that we may just as well introduce ourselves now.)

Our ramfs implementation is based on https://github.com/ctiedt/ramfs-loadable-module by @ctiedt (who is also our tutor and has prior work at https://github.com/ctiedt/rsramfs without the kernel crate). As none of us have worked on the linux kernel before and (in the context of the lecture) time was/is of the essence, the code is still a bit messy and doesn't always follow patterns that we found in the kernel crate (we don't have a FileSystemRegistration yet for example). We didn't write any original documentation yet either. It's nothing that can't be fixed though and we would be happy to do so.

In the next two weeks, we will also work on some basic benchmarks, which would also line up with the goals of this issue. Again, since our submission is due in a couple of weeks, we will probably not sync with your history or make our changes PR ready in this time. After that is done, we can focus on composing a sensible patch and we would be very excited to go through shorter iterations with your help, if that is in your interest.

In the meantime, you can all feel free to inspect or test the changes we made or reach out to us if you want to work together though! Our most recent work is on the fat branch of our fork, for the "stable" implementation of ramfs, I would rather advice the main branch :)

[ojeda]

@niklasmohrin, @bewee, @TheGrayStone, @taminob: welcome!

Thanks for letting us know -- it is great to know the things that people are working on, for a few reasons: we can tell upstream we have more users, you can tell us any problems you may have had, others can avoid working on the very same things (or collaborate, of course!), etc.

It is reasonable that your lecturer does not allow you to take contributions until grading is over, so do not worry for the next few weeks, and good luck on your exams/grades!

[foxhlchen]

Hey everyone! First things first, thank you all for your work on the Linux kernel :)

We, that is @bewee @TheGrayStone @taminob and me, have been working on implementing a file system using the kernel crate for a couple of months now. In fact, we have a running implementation of ramfs too, with a lot of the needed Rust abstractions. We would be very excited to work with all of you.

Our work is part of a lecture at university and we would have to come to an agreement with the lecturer before being able to take contributions to our branch, in case that is in anyone's interest. These constraints are of course lifted when the grading process is done. (Due to the same reasons, we originally wanted to wait until the end of the semester to contact you, but after we saw this issue, we felt that we may just as well introduce ourselves now.)

Our ramfs implementation is based on https://github.com/ctiedt/ramfs-loadable-module by @ctiedt (who is also our tutor and has prior work at https://github.com/ctiedt/rsramfs without the kernel crate). As none of us have worked on the linux kernel before and (in the context of the lecture) time was/is of the essence, the code is still a bit messy and doesn't always follow patterns that we found in the kernel crate (we don't have a FileSystemRegistration yet for example). We didn't write any original documentation yet either. It's nothing that can't be fixed though and we would be happy to do so.

In the next two weeks, we will also work on some basic benchmarks, which would also line up with the goals of this issue. Again, since our submission is due in a couple of weeks, we will probably not sync with your history or make our changes PR ready in this time. After that is done, we can focus on composing a sensible patch and we would be very excited to go through shorter iterations with your help, if that is in your interest.

In the meantime, you can all feel free to inspect or test the changes we made or reach out to us if you want to work together though! Our most recent work is on the fat branch of our fork, for the "stable" implementation of ramfs, I would rather advice the main branch :)

Wow, Great work!! It's nice that you guys have a working implementation already.
If I knew it, I wouldn't have written this from the ground up by myself.
You make me hesitant about whether to continue my implementation. :)

Can't wait to see the benchmark.
Again thanks for the work!!!