From: Andreas Hindborg <nmi@metaspace.dk>
To: Jens Axboe <axboe@kernel.dk>
Cc: "Keith Busch" <kbusch@kernel.org>,
"Bart Van Assche" <bvanassche@acm.org>,
"Christoph Hellwig" <hch@lst.de>,
"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>,
"Benno Lossin" <benno.lossin@proton.me>,
"open list" <linux-kernel@vger.kernel.org>,
gost.dev@samsung.com
Subject: Re: [RFC PATCH 00/11] Rust null block driver
Date: Fri, 05 May 2023 07:06:55 +0200 [thread overview]
Message-ID: <87sfcbs6ho.fsf@metaspace.dk> (raw)
In-Reply-To: <0adf4086-c624-1587-d490-9e6bb517afe0@kernel.dk>
Jens Axboe <axboe@kernel.dk> writes:
> On 5/4/23 1:59?PM, Andreas Hindborg wrote:
>>
>> Jens Axboe <axboe@kernel.dk> writes:
>>
>>> On 5/4/23 12:52?PM, Keith Busch wrote:
>>>> On Thu, May 04, 2023 at 11:36:01AM -0700, Bart Van Assche wrote:
>>>>> On 5/4/23 11:15, Andreas Hindborg wrote:
>>>>>> If it is still unclear to you why this effort was started, please do let
>>>>>> me know and I shall try to clarify further :)
>>>>>
>>>>> It seems like I was too polite in my previous email. What I meant is that
>>>>> rewriting code is useful if it provides a clear advantage to the users of
>>>>> a driver. For null_blk, the users are kernel developers. The code that has
>>>>> been posted is the start of a rewrite of the null_blk driver. The benefits
>>>>> of this rewrite (making low-level memory errors less likely) do not outweigh
>>>>> the risks that this effort will introduce functional or performance regressions.
>>>>
>>>> Instead of replacing, would co-existing be okay? Of course as long as
>>>> there's no requirement to maintain feature parity between the two.
>>>> Actually, just call it "rust_blk" and declare it has no relationship to
>>>> null_blk, despite their functional similarities: it's a developer
>>>> reference implementation for a rust block driver.
>>>
>>> To me, the big discussion point isn't really whether we're doing
>>> null_blk or not, it's more if we want to go down this path of
>>> maintaining rust bindings for the block code in general. If the answer
>>> to that is yes, then doing null_blk seems like a great choice as it's
>>> not a critical piece of infrastructure. It might even be a good idea to
>>> be able to run both, for performance purposes, as the bindings or core
>>> changes.
>>>
>>> But back to the real question... This is obviously extra burden on
>>> maintainers, and that needs to be sorted out first. Block drivers in
>>> general are not super security sensitive, as it's mostly privileged code
>>> and there's not a whole lot of user visibile API. And the stuff we do
>>> have is reasonably basic. So what's the long term win of having rust
>>> bindings? This is a legitimate question. I can see a lot of other more
>>> user exposed subsystems being of higher interest here.
>>
>> Even though the block layer is not usually exposed in the same way
>> that something like the USB stack is, absence of memory safety bugs is
>> a very useful property. If this is attainable without sacrificing
>> performance, it seems like a nice option to offer future block device
>> driver developers. Some would argue that it is worth offering even in
>> the face of performance regression.
>>
>> While memory safety is the primary feature that Rust brings to the
>> table, it does come with other nice features as well. The type system,
>> language support stackless coroutines and error handling language
>> support are all very useful.
>
> We're in violent agreement on this part, I don't think anyone sane would
> argue that memory safety with the same performance [1] isn't something
> you'd want. And the error handling with rust is so much better than the
> C stuff drivers do now that I can't see anyone disagreeing on that being
> a great thing as well.
>
> The discussion point here is the price being paid in terms of people
> time.
>
>> Regarding maintenance of the bindings, it _is_ an amount extra work. But
>> there is more than one way to structure that work. If Rust is accepted
>> into the block layer at some point, maintenance could be structured in
>> such a way that it does not get in the way of existing C maintenance
>> work. A "rust keeps up or it breaks" model. That could work for a while.
>
> That potentially works for null_blk, but it would not work for anything
> that people actually depend on. In other words, anything that isn't
> null_blk. And I don't believe we'd be actively discussing these bindings
> if just doing null_blk is the end goal, because that isn't useful by
> itself, and at that point we'd all just be wasting our time. In the real
> world, once we have just one actual driver using it, then we'd be
> looking at "this driver regressed because of change X/Y/Z and that needs
> to get sorted before the next release". And THAT is the real issue for
> me. So a "rust keeps up or it breaks" model is a bit naive in my
> opinion, it's just not a viable approach. In fact, even for null_blk,
> this doesn't really fly as we rely on blktests to continually vet the
> sanity of the IO stack, and null_blk is an integral part of that.
Sure, once there are actual users, this model would not work. But during
an introduction period it might be a useful model. Having Rust around
without having to take care of it might give
maintainers,reviewers,contributors a no strings attached opportunity to
dabble with the language in a domain they are familiar with.
>
> So I really don't think there's much to debate between "rust people vs
> jens" here, as we agree on the benefits, but my end of the table has to
> stomach the cons. And like I mentioned in an earlier email, that's not
> just on me, there are other regular contributors and reviewers that are
> relevant to this discussion. This is something we need to discuss.
>
> [1] We obviously need to do real numbers here, the ones posted I don't
> consider stable enough to be useful in saying "yeah it's fully on part".
> If you have an updated rust nvme driver that uses these bindings I'd
> be happy to run some testing that will definitively tell us if there's a
> performance win, loss, or parity, and how much.
I do plan to rebase the NVMe driver somewhere in the next few months.
I'll let you know when that work is done.
Best regards
Andreas
next prev parent reply other threads:[~2023-05-05 5:16 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
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 [this message]
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=87sfcbs6ho.fsf@metaspace.dk \
--to=nmi@metaspace.dk \
--cc=Damien.LeMoal@wdc.com \
--cc=alex.gaynor@gmail.com \
--cc=axboe@kernel.dk \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--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=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).