From: Benno Lossin <benno.lossin@proton.me>
To: "Andreas Hindborg (Samsung)" <nmi@metaspace.dk>
Cc: "Jens Axboe" <axboe@kernel.dk>, "Christoph Hellwig" <hch@lst.de>,
"Keith Busch" <kbusch@kernel.org>,
"Damien Le Moal" <Damien.LeMoal@wdc.com>,
"Hannes Reinecke" <hare@suse.de>,
lsf-pc@lists.linux-foundation.org,
rust-for-linux@vger.kernel.org, linux-block@vger.kernel.org,
"Matthew Wilcox" <willy@infradead.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
linux-kernel@vger.kernel.org, gost.dev@samsung.com
Subject: Re: [RFC PATCH 03/11] rust: block: introduce `kernel::block::mq` module
Date: Tue, 23 Jan 2024 16:14:58 +0000 [thread overview]
Message-ID: <104a22f7-a5bb-4fb6-9ce9-aa2d4e63417f@proton.me> (raw)
In-Reply-To: <87il3kjgk0.fsf@metaspace.dk>
Hi Andreas,
just so you know, I received this email today, so it was very late,
since the send date is January 12.
On 12.01.24 10:18, Andreas Hindborg (Samsung) wrote:
>
> Hi Benno,
>
> Benno Lossin <benno.lossin@proton.me> writes:
>
> <...>
>
>>> diff --git a/rust/kernel/block/mq/gen_disk.rs b/rust/kernel/block/mq/gen_disk.rs
>>> new file mode 100644
>>> index 000000000000..50496af15bbf
>>> --- /dev/null
>>> +++ b/rust/kernel/block/mq/gen_disk.rs
>>> @@ -0,0 +1,133 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +//! GenDisk abstraction
>>> +//!
>>> +//! C header: [`include/linux/blkdev.h`](../../include/linux/blkdev.h)
>>> +//! C header: [`include/linux/blk_mq.h`](../../include/linux/blk_mq.h)
>>> +
>>> +use crate::block::mq::{raw_writer::RawWriter, Operations, TagSet};
>>> +use crate::{
>>> + bindings, error::from_err_ptr, error::Result, sync::Arc, types::ForeignOwnable,
>>> + types::ScopeGuard,
>>> +};
>>> +use core::fmt::{self, Write};
>>> +
>>> +/// A generic block device
>>> +///
>>> +/// # Invariants
>>> +///
>>> +/// - `gendisk` must always point to an initialized and valid `struct gendisk`.
>>> +pub struct GenDisk<T: Operations> {
>>> + _tagset: Arc<TagSet<T>>,
>>> + gendisk: *mut bindings::gendisk,
>>
>> Why are these two fields not embedded? Shouldn't the user decide where
>> to allocate?
>
> The `TagSet` can be shared between multiple `GenDisk`. Using an `Arc`
> seems resonable?
>
> For the `gendisk` field, the allocation is done by C and the address
> must be stable. We are owning the pointee and must drop it when it goes out
> of scope. I could do this:
>
> #[repr(transparent)]
> struct GenDisk(Opaque<bindings::gendisk>);
>
> struct UniqueGenDiskRef {
> _tagset: Arc<TagSet<T>>,
> gendisk: Pin<&'static mut GenDisk>,
>
> }
>
> but it seems pointless. `struct GenDisk` would not be pub in that case. What do you think?
Hmm, I am a bit confused as to how you usually use a `struct gendisk`.
You said that a `TagSet` might be shared between multiple `GenDisk`s,
but that is not facilitated by the C side?
Is it the case that on the C side you create a struct containing a
tagset and a gendisk for every block device you want to represent?
And you decided for the Rust abstractions that you want to have only a
single generic struct for any block device, distinguished by the generic
parameter?
I think these kinds of details would be nice to know. Not only for
reviewers, but also for veterans of the C APIs.
--
Cheers,
Benno
next prev parent reply other threads:[~2024-01-23 16:15 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 9:06 [RFC PATCH 00/11] Rust null block driver Andreas Hindborg
2023-05-03 9:06 ` [RFC PATCH 01/11] rust: add radix tree abstraction Andreas Hindborg
2023-05-03 10:34 ` Benno Lossin
2023-05-05 4:04 ` Matthew Wilcox
2023-05-05 4:49 ` Andreas Hindborg
2023-05-05 5:28 ` Matthew Wilcox
2023-05-05 6:09 ` Christoph Hellwig
2023-05-05 8:33 ` Chaitanya Kulkarni
2023-05-03 9:06 ` [RFC PATCH 02/11] rust: add `pages` module for handling page allocation Andreas Hindborg
2023-05-03 12:31 ` Benno Lossin
2023-05-03 12:38 ` Benno Lossin
2023-05-05 4:09 ` Matthew Wilcox
2023-05-05 4:42 ` Andreas Hindborg
2023-05-05 5:29 ` Matthew Wilcox
2023-05-03 9:07 ` [RFC PATCH 03/11] rust: block: introduce `kernel::block::mq` module Andreas Hindborg
2023-05-08 12:29 ` Benno Lossin
2023-05-11 6:52 ` Sergio González Collado
2024-01-23 14:03 ` Andreas Hindborg (Samsung)
2024-01-12 9:18 ` Andreas Hindborg (Samsung)
2024-01-23 16:14 ` Benno Lossin [this message]
2024-01-23 18:39 ` Andreas Hindborg (Samsung)
2024-01-25 9:26 ` Benno Lossin
2024-01-29 14:14 ` Andreas Hindborg (Samsung)
2023-05-03 9:07 ` [RFC PATCH 04/11] rust: block: introduce `kernel::block::bio` module Andreas Hindborg
2023-05-08 12:58 ` Benno Lossin
2024-01-11 12:49 ` Andreas Hindborg (Samsung)
2024-02-28 14:31 ` Andreas Hindborg
2024-03-09 12:30 ` Benno Lossin
2023-05-03 9:07 ` [RFC PATCH 05/11] RUST: add `module_params` macro Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 06/11] rust: apply cache line padding for `SpinLock` Andreas Hindborg
2023-05-03 12:03 ` Alice Ryhl
2024-02-23 11:29 ` Andreas Hindborg (Samsung)
2024-02-26 9:15 ` Alice Ryhl
2023-05-03 9:07 ` [RFC PATCH 07/11] rust: lock: add support for `Lock::lock_irqsave` Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 08/11] rust: lock: implement `IrqSaveBackend` for `SpinLock` Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 09/11] RUST: implement `ForeignOwnable` for `Pin` Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 10/11] rust: add null block driver Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 11/11] rust: inline a number of short functions Andreas Hindborg
2023-05-03 11:32 ` [RFC PATCH 00/11] Rust null block driver Niklas Cassel
2023-05-03 12:29 ` Andreas Hindborg
2023-05-03 13:54 ` Niklas Cassel
2023-05-03 16:47 ` Bart Van Assche
2023-05-04 18:15 ` Andreas Hindborg
2023-05-04 18:36 ` Bart Van Assche
2023-05-04 18:46 ` Andreas Hindborg
2023-05-04 18:52 ` Keith Busch
2023-05-04 19:02 ` Jens Axboe
2023-05-04 19:59 ` Andreas Hindborg
2023-05-04 20:55 ` Jens Axboe
2023-05-05 5:06 ` Andreas Hindborg
2023-05-05 11:14 ` Miguel Ojeda
2023-05-04 20:11 ` Miguel Ojeda
2023-05-04 20:22 ` Jens Axboe
2023-05-05 10:53 ` Miguel Ojeda
2023-05-05 12:24 ` Boqun Feng
2023-05-05 13:52 ` Boqun Feng
2023-05-05 19:42 ` Keith Busch
2023-05-05 21:46 ` Boqun Feng
2023-05-05 19:38 ` Bart Van Assche
2023-05-05 3:52 ` Christoph Hellwig
2023-06-06 13:33 ` Andreas Hindborg (Samsung)
2023-06-06 14:46 ` Miguel Ojeda
2023-05-05 5:28 ` Hannes Reinecke
2023-05-07 23:31 ` Luis Chamberlain
2023-05-07 23:37 ` Andreas Hindborg
2023-07-27 3:45 ` Yexuan Yang
2023-07-27 3:47 ` Yexuan Yang
[not found] ` <2B3CA5F1CCCFEAB2+20230727034517.GB126117@1182282462>
2023-07-28 6:49 ` Andreas Hindborg (Samsung)
2023-07-31 14:14 ` Andreas Hindborg (Samsung)
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=104a22f7-a5bb-4fb6-9ce9-aa2d4e63417f@proton.me \
--to=benno.lossin@proton.me \
--cc=Damien.LeMoal@wdc.com \
--cc=alex.gaynor@gmail.com \
--cc=axboe@kernel.dk \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=nmi@metaspace.dk \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
--cc=willy@infradead.org \
/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).