From: Kent Overstreet <kent.overstreet@linux.dev>
To: Thomas Bertschinger <tahbertschinger@gmail.com>
Cc: Ariel Miculas <ariel.miculas@gmail.com>, rust-for-linux@vger.kernel.org
Subject: rust traits in kernel (was: bcachefs meeting)
Date: Thu, 7 Mar 2024 21:04:08 -0500 [thread overview]
Message-ID: <np7mqkkrnpvi4stflwkrrw7uew4fgkt6iqynmoiirxg4sdsjpj@dwnx334lctpk> (raw)
In-Reply-To: <20240308014248.GB66553@fedora-laptop>
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.
next parent reply other threads:[~2024-03-08 2:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <hveywufltgcwqs6gciwuqyse7gv3k6fhvqftnjtc6no76ajdhb@6ro24ggp6qdp>
[not found] ` <CAPDJoNunCinSA9Y=V5yEiFzTc7QU71Z=XKicJKNCQhDJEm0ROg@mail.gmail.com>
[not found] ` <20240308003235.GA66553@fedora-laptop>
[not found] ` <eqixbuwkcqmllbkoszgxxkyo6rj2izq3h5c4m7jtehbbyzqyt5@7upygcsju5ge>
[not found] ` <20240308014248.GB66553@fedora-laptop>
2024-03-08 2:04 ` Kent Overstreet [this message]
2024-03-08 17:43 ` rust traits in kernel Josh Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=np7mqkkrnpvi4stflwkrrw7uew4fgkt6iqynmoiirxg4sdsjpj@dwnx334lctpk \
--to=kent.overstreet@linux.dev \
--cc=ariel.miculas@gmail.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=tahbertschinger@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).