From: "Benno Lossin" <lossin@kernel.org>
To: "Sidong Yang" <sidong.yang@furiosa.ai>,
"Caleb Sander Mateos" <csander@purestorage.com>
Cc: "Daniel Almeida" <daniel.almeida@collabora.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>, "Jens Axboe" <axboe@kernel.dk>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<io-uring@vger.kernel.org>
Subject: Re: [RFC PATCH v2 2/4] rust: io_uring: introduce rust abstraction for io-uring cmd
Date: Sat, 09 Aug 2025 22:22:06 +0200 [thread overview]
Message-ID: <DBY6DMQYZ2CL.2P0LZO2HF13MJ@kernel.org> (raw)
In-Reply-To: <aJdEbFI2FqSCBt9L@sidongui-MacBookPro.local>
On Sat Aug 9, 2025 at 2:51 PM CEST, Sidong Yang wrote:
> On Sat, Aug 09, 2025 at 12:18:49PM +0200, Benno Lossin wrote:
>> We'd need to ensure that `borrow_pdu` can only be called if `store_pdu`
>> has been called before. Is there any way we can just ensure that pdu is
>> always initialized? Like a callback that's called once, before the value
>> is used at all?
>
> I've thought about this. As Celab said, returning `&mut MaybeUninit<[u8;32]> is
> simple and best. Only driver knows it's initialized. There is no way to
> check whether it's initialized with reading the pdu. The best way is to return
> `&mut MaybeUninit<[u8;32]>` and driver initializes it in first time. After
> init, driver knows it's guranteed that it's initialized so it could call
> `assume_init_mut()`. And casting to other struct is another problem. The driver
> is responsible for determining how to interpret the PDU, whether by using it
> directly as a byte array or by performing an unsafe cast to another struct.
But then drivers will have to use `unsafe` & possibly cast the slice to
a struct? I think that's bad design since we try to avoid unsafe code in
drivers as much as possible. Couldn't we try to ensure from the
abstraction side that any time you create such an object, the driver
needs to provide the pdu data? Or we could make it implement `Default`
and then set it to that before handing it to the driver.
---
Cheers,
Benno
next prev parent reply other threads:[~2025-08-09 20:22 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-27 15:03 [RFC PATCH v2 0/4] rust: miscdevice: abstraction for uring-cmd Sidong Yang
2025-07-27 15:03 ` [RFC PATCH v2 1/4] rust: bindings: add io_uring headers in bindings_helper.h Sidong Yang
2025-07-27 15:03 ` [RFC PATCH v2 2/4] rust: io_uring: introduce rust abstraction for io-uring cmd Sidong Yang
2025-08-01 13:48 ` Daniel Almeida
2025-08-02 10:52 ` Benno Lossin
2025-08-06 12:38 ` Daniel Almeida
2025-08-06 13:38 ` Benno Lossin
2025-08-08 6:56 ` Sidong Yang
2025-08-08 8:49 ` Benno Lossin
2025-08-08 9:43 ` Sidong Yang
2025-08-09 10:18 ` Benno Lossin
2025-08-09 12:51 ` Sidong Yang
2025-08-09 20:22 ` Benno Lossin [this message]
2025-08-10 13:50 ` Sidong Yang
2025-08-10 14:27 ` Daniel Almeida
2025-08-10 14:46 ` Sidong Yang
2025-08-10 20:06 ` Benno Lossin
2025-08-11 12:34 ` Sidong Yang
2025-08-11 12:44 ` Daniel Almeida
2025-08-11 14:50 ` Sidong Yang
2025-08-12 8:34 ` Benno Lossin
2025-08-12 12:19 ` Sidong Yang
2025-08-12 12:43 ` Daniel Almeida
2025-08-12 13:56 ` Sidong Yang
2025-08-12 13:59 ` Daniel Almeida
2025-08-12 14:38 ` Daniel Almeida
2025-08-13 0:54 ` Sidong Yang
2025-08-08 13:55 ` Caleb Sander Mateos
2025-08-09 12:53 ` Sidong Yang
2025-08-05 3:39 ` Sidong Yang
2025-08-05 13:02 ` Daniel Almeida
2025-08-06 9:11 ` Sidong Yang
2025-07-27 15:03 ` [RFC PATCH v2 3/4] rust: miscdevice: add uring_cmd() for MiscDevice trait Sidong Yang
2025-08-01 14:04 ` Daniel Almeida
2025-08-07 7:46 ` Sidong Yang
2025-07-27 15:03 ` [RFC PATCH v2 4/4] samples: rust: rust_misc_device: add uring_cmd example Sidong Yang
2025-08-01 14:11 ` Daniel Almeida
2025-08-07 6:30 ` Sidong Yang
2025-07-27 17:17 ` [RFC PATCH v2 0/4] rust: miscdevice: abstraction for uring-cmd Daniel Almeida
2025-08-01 14:13 ` Daniel Almeida
2025-08-07 6:17 ` Sidong Yang
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=DBY6DMQYZ2CL.2P0LZO2HF13MJ@kernel.org \
--to=lossin@kernel.org \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=daniel.almeida@collabora.com \
--cc=gregkh@linuxfoundation.org \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sidong.yang@furiosa.ai \
/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 NNTP newsgroup(s).