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
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?
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?? 🤔
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.
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 :)
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!
Reacted by Tamino Bauknecht, Benedikt Weber, kloenk, Niklas Mohrin, Nils Lissner, Josef Grieb and Hassan Khan
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!!!
Activity
foxhlchen commentedon Jun 9, 2021
I was actually thinking about writing a
debugfsin 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 commentedon Jun 9, 2021
debugfsis good as well;ramfsis much simpler though :)ramfsis 641 LOC in C anddebugfsin 2048 LOC.foxhlchen commentedon Jun 9, 2021
IIUC,
Tmpfs/ramfsis bound with the driver model and device tree. it's implemented under mm/debugfsis a normal fs.nbdd0121 commentedon Jun 9, 2021
tmpfsis andramfsis just a normal fs. I'll droptmpfsfrom the title.foxhlchen commentedon Jun 9, 2021
But whatsoever, the idea is to implement a simple in-memory filesystem. Both of them are ok. :D
[-]tmpfs/ramfs as an example/benchmark[/-][+]ramfs as an example/benchmark[/+]ojeda commentedon Jun 9, 2021
No specific plan from me, so please feel free to work on an example filesystem and/or benchmark!
foxhlchen commentedon Jun 9, 2021
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 commentedon Jun 9, 2021
If you want to work on it, go for it! I'll be happy to offer help or advices whenever you need them ;)
foxhlchen commentedon Jun 10, 2021
Wow! Thank you!!
smiller123 commentedon Jul 3, 2021
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 commentedon Jul 4, 2021
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
FileSystemRegistrationyet 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
fatbranch of our fork, for the "stable" implementation of ramfs, I would rather advice the main branch :)ojeda commentedon Jul 4, 2021
@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 commentedon Jul 5, 2021
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!!!