[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPYDY8mdHWjyOU3l@google.com>
Date: Mon, 20 Oct 2025 09:39:47 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: gregkh@...uxfoundation.org, rafael@...nel.org, ojeda@...nel.org,
alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net,
bjorn3_gh@...tonmail.com, lossin@...nel.org, a.hindborg@...nel.org,
tmgross@...ch.edu, mmaurer@...gle.com, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/7] rust: debugfs: support for binary large objects
On Mon, Oct 20, 2025 at 11:35:15AM +0200, Danilo Krummrich wrote:
> On Mon Oct 20, 2025 at 10:13 AM CEST, Alice Ryhl wrote:
> > I ended up using i64 for simple_read_from_buffer in iov.rs instead of
> > loff_t. But if they can differ, then yeah let's introduce a loff_t type
> > alias.
>
> No, I don't think they can differ (I used i64 in earlier version that didn't
> make it to the list as well), but I think it could still make sense to indicate
> the relationship with loff_t. When I see an i64, an offset into a buffer is not
> the first thing that comes to my mind.
>
> What about uaccess::Offset?
Hmm. That seems wrong. loff_t is a *file position*, so it should go in
kernel::fs, right? We're only using it in uaccess/iov because they
happen to have utility methods to help with implementing fops entries.
None of the "base" uaccess/iov functions use loff_t for anything since
they deal with sizes in the address space, for which usize is the
correct type.
Alice
Powered by blists - more mailing lists