rust traits in kernel (was: bcachefs meeting)

rust traits in kernel (was: bcachefs meeting)

[Kent Overstreet]

On Thu, Mar 07, 2024 at 06:42:48PM -0700, Thomas Bertschinger wrote:
> On Thu, Mar 07, 2024 at 08:02:14PM -0500, Kent Overstreet wrote:
> > That works - you guys want to pick the time then? I'm the more flexible
> > one.
> > 
> How about Wednesday after 8pm UTC, or Thursday after 9:30pm UTC, or
> any time on Friday?
> 
> > > I'll give a quick update on what I've been working on since it's been a
> > > bit since I've shared anything concrete. I'm trying to create generally
> > > useful Rust wrappers for the debugfs_*() functions. Currently, working
> > > on:
> > > 
> > > debugfs_create_file_from_iter(parent_dentry, &T)
> > > 
> > > where T implements IntoIter and T::item implements Display.
> > > 
> > > This should create a debugfs file where read() returns the Display
> > > format of each item of the iterator. Bcachefs definitely wants this for
> > > the btree iterators, but I think this seems like a generally useful tool
> > > so it would be nice to try to make a good generic interface.
> > > 
> > > Right now I am working through some interesting lifetime / ownership
> > > issues that this presents. I can share more details in IRC or in our
> > > meeting, and hopefully will share something concrete with the mailing
> > > lists soon, once I have the code working and presentable.
> > 
> > Ok, that should work.
> > 
> > Did you consider the bytestream iterator approach? That's a more low
> > levnel approach, but it feels to me like something we're going to want
> > too. But if this seems like the most straightforward appraoch this
> > totally works.
>  
> That's a good point, the bytestream approach is more versatile. I have
> thought about it a little but I have not attempted to implement it yet,
> but I can try implementing it and see if it's cleaner that the iterator
> approach.
> 
> I think we would want something like the BufRead trait to make that
> work. The std::io::BufRead trait isn't available in the kernel so a
> similar trait would need to be defined. If it is defined, then
>
> debugfs_create_file_from_bufread(...)
> 
> should hopefully be pretty straightforward to implement.

yeah, that does look like what we want. Let's see if we can find out
what'll be required to pull it in, it shouldn't be much code.

> > 
> > How are the lifetime issues looking? 
> 
> This works by passing a pointer to the object that implements
> IntoIterator through the struct inode's private data, and then in the
> open() method I try to dereference that pointer and call the type's
> into_iter() method to get an iterator. A pointer to that iterator
> object is then passed via the struct file's private data to read().
> 
> The problem is that Rust refuses to call into_iter() on the dereferenced
> raw pointer because into_iter() requires taking ownership of the object,
> but Rust (correctly, from a memory safety point of view) refuses to take
> ownership of an object behind a raw pointer--even in an unsafe block. Of
> course, I know that the IntoIterator object was allocated on the Rust
> side in the first place but the compiler doesn't know that.
> 
> I think the most straightforward solution is to require that the
> IntoIterator object also implement Clone and then clone() it. But it
> might also be possible to also use another layer of indirection with an
> Rc<> or Arc<>, but I haven't explored that solution yet.

IntoIterator isn't the only way of getting an iterator. This comes up
with vectors as well, where often you want to be able to iterate over a
vector without consuming it.

So vectors have a .iter() method that returns an iterator that just
takes a reference to the original vector. I don't think there's a
standard trait for this "borrowed iterator" method, but it's a standard
thing for container objects - that's what we'll want to do here.

Re: rust traits in kernel

[Josh Stone]

On 3/7/24 6:04 PM, Kent Overstreet wrote:
> IntoIterator isn't the only way of getting an iterator. This comes up
> with vectors as well, where often you want to be able to iterate over a
> vector without consuming it.
> 
> So vectors have a .iter() method that returns an iterator that just
> takes a reference to the original vector. I don't think there's a
> standard trait for this "borrowed iterator" method, but it's a standard
> thing for container objects - that's what we'll want to do here.

There's also `impl<T> IntoIterator for &Vec<T>` that does the same thing
as the slice .iter(), and this lets `for x in &vec` work for borrowed
items. So there's not a separate trait, just IntoIterator taking
ownership of a reference instead of the actual container.