From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 958292E7BD4; Tue, 12 Aug 2025 08:35:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754987700; cv=none; b=O6iWzPh43vQA/nAg1qmsOPDHIlymp0e3bkv3Ac3BDFyurHpTF1PdruWWMYhOKlWqi5wS5PkgZsGzuTR+y4+oqvio6nTf6WLAl62vN9xMBRjuIrORXgsDAu4jkIOxrGcbreyz1qNgkD+Y0X1RUeyboyEHNI8YFrDPH3jbC1AsylQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754987700; c=relaxed/simple; bh=xTdISAyT0Kzubsk+Rx8mfxAyPYBnzZHTr/cxp81IiDg=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=c/a1MK95UztSAp92zzG41/5KY/0T+rZp+4fv6aUb1lNlwHPpJzNqNf9o0u4gTLG0pieEa6inXwEBfEN0BiSwD2zE6RjKviCijHryOTv9/cKAK9JjbAnLvffukxbi4rLq4EHay2f+ShrrjD44LaRiOn+v3dI7+DX3SFtPxyDzSNc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hkd2yKo/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hkd2yKo/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CAF6C4CEF4; Tue, 12 Aug 2025 08:34:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754987700; bh=xTdISAyT0Kzubsk+Rx8mfxAyPYBnzZHTr/cxp81IiDg=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=Hkd2yKo/gVbX3VsamhkYHbKRttvNnisB93+cA9XGxZfcrtke2QmefE7w9fBcu4aNx lCl9WtvZPEtgJMy/Q3qMk/jM6jAsOLWjY0SFwp4ZEwYfsw5G5vadd5n7V5sGU/XH9X QGbzBfaj+bmwgJVQ3LdJGOqjubLphcJeRxq8Vto1fro5FFQEIBWnwLNgd9vpT6N0lY fk+ySHit55c3ow/+ej6DSWoP1cMnk4bWASbJq8BOG5de7YIWjNc1jLGKJrqt04m8Ym 2lzpPsSfJsTLsxYEJ8eypyTAYB39tq8GEWkL0FfXapB7IILpjYrvJg2WJMElCk86b6 oDhIwd0yKqweA== Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 12 Aug 2025 10:34:56 +0200 Message-Id: Cc: "Caleb Sander Mateos" , "Miguel Ojeda" , "Arnd Bergmann" , "Jens Axboe" , "Greg Kroah-Hartman" , , , Subject: Re: [RFC PATCH v2 2/4] rust: io_uring: introduce rust abstraction for io-uring cmd From: "Benno Lossin" To: "Sidong Yang" , "Daniel Almeida" X-Mailer: aerc 0.20.1 References: <81C84BD8-D99C-4103-A280-CFC71DF58E3B@collabora.com> <8416C381-A654-41D4-A731-323CEDE58BB1@collabora.com> In-Reply-To: On Mon Aug 11, 2025 at 4:50 PM CEST, Sidong Yang wrote: > On Mon, Aug 11, 2025 at 09:44:22AM -0300, Daniel Almeida wrote: >> > There is `uring_cmd` callback in `file_operation` at c side. `Pin<&mut= IoUringCmd>` >> > would be create in the callback function. But the callback function co= uld be >> > called repeatedly with same `io_uring_cmd` instance as far as I know. >> >=20 >> > But in c side, there is initialization step `io_uring_cmd_prep()`. >> > How about fill zero pdu in `io_uring_cmd_prep()`? And we could assign = a byte >> > as flag in pdu for checking initialized also we should provide 31 byte= s except >> > a byte for the flag. >> >=20 >>=20 >> That was a follow-up question of mine. Can=C2=B4t we enforce zero-initia= lization >> in C to get rid of this MaybeUninit? Uninitialized data is just bad in g= eneral. >>=20 >> Hopefully this can be done as you've described above, but I don't want t= o over >> extend my opinion on something I know nothing about. > > I need to add a commit that initialize pdu in prep step in next version.= =20 > I'd like to get a comment from io_uring maintainer Jens. Thanks. > > If we could initialize (filling zero) in prep step, How about casting iss= ue? > Driver still needs to cast array to its private struct in unsafe? We still would have the casting issue. Can't we do the following: * Add a new associated type to `MiscDevice` called `IoUringPdu` that has to implement `Default` and have a size of at most 32 bytes. * make `IoUringCmd` generic * make `MiscDevice::uring_cmd` take `Pin<&mut IoUringCmd>= ` * initialize the private data to be `IoUringPdu::default()` when we create the `IoUringCmd` object. * provide a `fn pdu(&mut self) -> &mut Pdu` on `IoUringPdu`. Any thoughts? If we don't want to add a new associated type to `MiscDevice` (because not everyone has to declare the `IoUringCmd` data), I have a small trait dance that we can do to avoid that: pub trait IoUringMiscDevice: MiscDevice { type IoUringPdu: Default; // missing the 32 byte constraint } and then in MiscDevice we still add this function: fn uring_cmd( _device: ::Borrowed<'_>, _io_uring_cmd: Pin<&mut IoUringCmd>, _issue_flags: u32, ) -> Result where Self: IoUringMiscDevice, { build_error!(VTABLE_DEFAULT_ERROR) } It can only be called when the user also implements `IoUringMiscDevice`. --- Cheers, Benno