Message ID | 20220802015052.10452-1-ojeda@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | Rust support | expand |
On Tue, Aug 02, 2022 at 03:49:47AM +0200, Miguel Ojeda wrote: > Some of the improvements to the abstractions and example drivers are: > > - Filesystem support (`fs` module), including: > > + `INode` type (which wraps `struct inode`). > + `DEntry` type (which wraps `struct dentry`). > + `Filename` type (which wraps `struct filename`). > + `Registration` type. > + `Type` and `Context` traits. > + `SuperBlock` type (which wraps `struct super_block` and takes > advantage of typestates for its initialization). > + File system parameters support (with a `Value` enum; `Spec*` > and `Constant*` types, `define_fs_params!` macro...). > + File system flags. > + `module_fs!` macro to simplify registering kernel modules that > only implement a single file system. > + A file system sample. None of this (afaict) has been discussed on linux-fsdevel. And I may have missed somethiing, but I don't see the fs module in this series of patches. Could linux-fsdevel be cc'd on the development of Rust support for filesystems in the future?
Hi Willy, On Tue, Aug 2, 2022 at 2:26 PM Matthew Wilcox <willy@infradead.org> wrote: > > None of this (afaict) has been discussed on linux-fsdevel. And I may > have missed somethiing, but I don't see the fs module in this series > of patches. Could linux-fsdevel be cc'd on the development of Rust > support for filesystems in the future? In order to provide example drivers and kernel modules, we need to have some safe abstractions for them, thus we are adding some as we need them. More importantly, the abstractions also serve as a showcase of how they may be written in the future if Rust support is merged. This does not mean these abstractions are a final design or that we plan to develop them independently of subsystem maintainers. In fact, we would prefer the opposite: in the future, when the support is merged and more people start having more experience with Rust, we hope that the respective kernel maintainers start developing and maintaining the abstractions themselves. But we have to start somewhere, and at least provide enough examples to serve as guidance and to show that it is actually possible to write abstractions that restrict the amount of unsafe code. And, of course, if you are already interested in developing them, that would be actually great and we would love your input and/or that you join us. As for the `fs` module, I see in lore 2 patches didn't make it through, but I didn't get a bounce (I do get bounces for the rust-for-linux ML, but I was told that was fine as long as LKML got them). Sorry about that... I will ask what to do. Meanwhile, you can see the patches in this branch: https://github.com/Rust-for-Linux/linux.git rust-next Cheers, Miguel
Miguel, handwaiving and pointing to git trees is not how Linux development works. Please make sure all the patches go to the relevant lists and maintainers first, and actually do have ACKs.
On Tue, Aug 02, 2022 at 03:45:50PM +0200, Miguel Ojeda wrote: > Hi Willy, > > On Tue, Aug 2, 2022 at 2:26 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > None of this (afaict) has been discussed on linux-fsdevel. And I may > > have missed somethiing, but I don't see the fs module in this series > > of patches. Could linux-fsdevel be cc'd on the development of Rust > > support for filesystems in the future? > > In order to provide example drivers and kernel modules, we need to > have some safe abstractions for them, thus we are adding some as we > need them. > > More importantly, the abstractions also serve as a showcase of how > they may be written in the future if Rust support is merged. > > This does not mean these abstractions are a final design or that we > plan to develop them independently of subsystem maintainers. In fact, > we would prefer the opposite: in the future, when the support is > merged and more people start having more experience with Rust, we hope > that the respective kernel maintainers start developing and > maintaining the abstractions themselves. > > But we have to start somewhere, and at least provide enough examples > to serve as guidance and to show that it is actually possible to write > abstractions that restrict the amount of unsafe code. > > And, of course, if you are already interested in developing them, that > would be actually great and we would love your input and/or that you > join us. No objections to any of this. I love the idea of being able to write filesystems in Rust. I just think it would go more smoothly if linux-fsdevel were involved more closely so people at least have the option of being able to follow design decisions, and hopefully influence them. That goes both ways, of course; I hardly think our current operations structures are the optimum way to implement a filesystem, and having fresh eyes say things like "But that shouldn't be part of the address_space_operations" can impel better abstractions. > As for the `fs` module, I see in lore 2 patches didn't make it > through, but I didn't get a bounce (I do get bounces for the > rust-for-linux ML, but I was told that was fine as long as LKML got > them). Sorry about that... I will ask what to do. The obvious answer is to split out the 'fs module' into its own patch ;-) I presume it was part of the kernel crate which would have been either patch 17 or 11 in that series? > Meanwhile, you can see the patches in this branch: > > https://github.com/Rust-for-Linux/linux.git rust-next > > Cheers, > Miguel
On Tue, Aug 2, 2022 at 3:48 PM Christoph Hellwig <hch@infradead.org> wrote: > > handwaiving and pointing to git trees is not how Linux development > works. Please make sure all the patches go to the relevant lists > and maintainers first, and actually do have ACKs. Which hand-waving? In fact, we were requested to do it like this. As for the Cc's, if any ML wants to be Cc'd for an abstraction we create, even if no C code is modified on their side, I am more than happy to Cc them. I can even do that by default, but not everyone may want to hear about the Rust side just yet, so I have not been doing it so far. Cheers, Miguel
On Tue, Aug 2, 2022 at 4:01 PM Matthew Wilcox <willy@infradead.org> wrote: > > No objections to any of this. I love the idea of being able to write > filesystems in Rust. I just think it would go more smoothly if > linux-fsdevel were involved more closely so people at least have the > option of being able to follow design decisions, and hopefully influence > them. That goes both ways, of course; I hardly think our current > operations structures are the optimum way to implement a filesystem, > and having fresh eyes say things like "But that shouldn't be part of the > address_space_operations" can impel better abstractions. I will send the patches to fsdevel then! As for following development closely and design decisions, we have been doing it in GitHub so far pre-merge, so the easiest until the merge (for us) would be to ping you there. We can also send you copies of the `fs` related patches too if you would like that. I would highly recommend joining the monthly informal calls too. (I appreciate the kind answer, by the way!) > The obvious answer is to split out the 'fs module' into its own patch > ;-) I presume it was part of the kernel crate which would have been > either patch 17 or 11 in that series? Yeah, patch 17, exactly (patch 11 is the `alloc` import). I have asked Konstantin privately about them. In any case, I will split the patches further for v9 which should help. Meanwhile, you can also see the `fs` module here, if you are curious: https://github.com/Rust-for-Linux/linux/blob/rust-next/rust/kernel/fs.rs https://github.com/Rust-for-Linux/linux/blob/rust-next/rust/kernel/fs/param.rs Cheers, Miguel
On Tue, Aug 2, 2022 at 5:09 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > Yeah, patch 17, exactly (patch 11 is the `alloc` import). I have asked > Konstantin privately about them. The patches are showing up now in lore -- not sure if it was just a delay (which would be consistent with the lack of bounce) or somebody did something (thank you if so!). Cheers, Miguel