From: "Danilo Krummrich" <dakr@kernel.org>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: "Alexandre Courbot" <acourbot@nvidia.com>,
"gary@garyguo.net" <gary@garyguo.net>,
"nova-gpu@lists.linux.dev" <nova-gpu@lists.linux.dev>,
"Zhi Wang" <zhiw@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"John Hubbard" <jhubbard@nvidia.com>
Subject: Re: [PATCH 1/8] rust: firmware: add request_into_buf()
Date: Thu, 11 Jun 2026 21:18:31 +0200 [thread overview]
Message-ID: <DJ6GNNLVSRQ6.KEY8HC7A6T67@kernel.org> (raw)
In-Reply-To: <78734fd67dde42efa7fe02b031b67686e08b37a1.camel@nvidia.com>
On Thu Jun 11, 2026 at 6:32 PM CEST, Timur Tabi wrote:
> On Thu, 2026-06-11 at 15:49 +0900, Alexandre Courbot wrote:
>> > +/// the caller could mutate `buf` while reads via `data()` are outstanding (and
>> > +/// `release_firmware()` does not free `buf` anyway). Releasing the bookkeeping here and
>> > +/// returning only the size leaves `buf` as the single owner and accessor of the data.
>> > +pub fn request_into_buf(name: &CStr, dev: &Device, buf: &mut [u8]) -> Result<usize> {
>>
>> By adding a lifetime parameter you can return a `Result<&'a mut [u8]>`.
>> This is more sound as the caller cannot use the unwritten part of `buf`.
>> It is also more convenient as there is now no need to create a sub-slice
>> manually.
>
> Sorry, I don't understand. The caller allocates the buffer any way it wants and passes the
> slice. This function is basically a gloried memcpy, it doesn't care about lifetimes. Why would
> I want to add one? It even releases the `firmware` object before it exits, so there's no
> kernel-allocated data to retain, which is why it's not part of the Firmware struct.
It allows you to return a &'a mut [u8], where this is a sub-slice that is
already "trimmed" to the length of the actual firmware image loaded. This way
callers do not need to bother creating a sub-slice themselves.
The lifetime is required to tell the compiler which argument to infer the output
lifetime from.
fn request_into_buf<'a>(name: &CStr, dev: &Device, buf: &'a mut [u8]) -> Result<&'a mut [u8]>
This tells the compiler that the returned sub-slice must not outlive buf. Note
that the compiler does only look at the signature, not the function body.
>> "the caller cannot use the unwritten part of `buf`"
>
> Sure it can. It allocated the buffer, and passed a slice of the whole buffer or just a portion.
> After the function returns, the caller can do whatever it wants with the buffer, since it owns
> it outright.
True, but there is no reason for the caller to create the sub-slice on its own
anymore, i.e. the correct usage becomes the "path of least resistance".
next prev parent reply other threads:[~2026-06-11 19:18 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 17:49 [PATCH 0/8] Transition Nova Core to TLV firmware images Timur Tabi
2026-06-10 17:49 ` [PATCH 1/8] rust: firmware: add request_into_buf() Timur Tabi
2026-06-10 18:03 ` Gary Guo
2026-06-10 18:24 ` Timur Tabi
2026-06-10 20:26 ` Gary Guo
2026-06-10 20:28 ` Timur Tabi
2026-06-10 21:46 ` Danilo Krummrich
2026-06-11 4:58 ` Alexandre Courbot
2026-06-11 15:48 ` Timur Tabi
2026-06-11 6:49 ` Alexandre Courbot
2026-06-11 16:32 ` Timur Tabi
2026-06-11 19:18 ` Danilo Krummrich [this message]
2026-06-11 19:28 ` Timur Tabi
2026-06-11 19:31 ` John Hubbard
2026-06-11 20:01 ` Timur Tabi
2026-06-11 21:55 ` John Hubbard
2026-06-11 21:56 ` Danilo Krummrich
2026-06-11 21:49 ` Danilo Krummrich
2026-06-12 2:59 ` Alexandre Courbot
2026-06-12 14:51 ` Alexandre Courbot
2026-06-10 17:49 ` [PATCH 2/8] gpu: nova-core: add request_tlv to load TLV images Timur Tabi
2026-06-10 22:00 ` Danilo Krummrich
2026-06-11 16:45 ` Timur Tabi
2026-06-11 18:17 ` Gary Guo
2026-06-11 18:26 ` Timur Tabi
2026-06-11 18:42 ` Gary Guo
2026-06-11 18:53 ` Timur Tabi
2026-06-11 19:16 ` John Hubbard
2026-06-11 18:53 ` Danilo Krummrich
2026-06-11 18:57 ` Timur Tabi
2026-06-10 17:49 ` [PATCH 3/8] gpu: nova-core: add TLV parser for firmware files Timur Tabi
2026-06-10 22:37 ` Danilo Krummrich
2026-06-11 6:51 ` Alexandre Courbot
2026-06-11 18:40 ` John Hubbard
2026-06-11 23:29 ` Timur Tabi
2026-06-12 14:46 ` Alexandre Courbot
2026-06-12 18:04 ` Timur Tabi
2026-06-12 23:27 ` Alexandre Courbot
2026-06-12 23:39 ` John Hubbard
2026-06-10 17:49 ` [PATCH 4/8] gpu: nova-core: transition booter_load to TLV images Timur Tabi
2026-06-10 17:49 ` [PATCH 5/8] gpu: nova-core: transition gsp " Timur Tabi
2026-06-10 17:49 ` [PATCH 6/8] gpu: nova-core: transition gen_bootloader " Timur Tabi
2026-06-10 17:49 ` [PATCH 7/8] gpu: nova-core: transition fsp " Timur Tabi
2026-06-10 17:49 ` [PATCH 8/8] gpu: nova-core: update firmware module info for " Timur Tabi
2026-06-12 15:02 ` Alexandre Courbot
2026-06-12 15:44 ` Timur Tabi
2026-06-10 18:16 ` [PATCH 0/8] Transition Nova Core to TLV firmware images John Hubbard
2026-06-10 18:19 ` Timur Tabi
2026-06-10 18:59 ` Timur Tabi
2026-06-10 21:21 ` John Hubbard
2026-06-10 21:43 ` Timur Tabi
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=DJ6GNNLVSRQ6.KEY8HC7A6T67@kernel.org \
--to=dakr@kernel.org \
--cc=acourbot@nvidia.com \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=nova-gpu@lists.linux.dev \
--cc=ttabi@nvidia.com \
--cc=zhiw@nvidia.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