[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 May 2023 13:14:58 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Andreas Hindborg <nmi@...aspace.dk>,
Keith Busch <kbusch@...nel.org>,
Bart Van Assche <bvanassche@....org>,
Christoph Hellwig <hch@....de>,
Damien Le Moal <Damien.LeMoal@....com>,
Hannes Reinecke <hare@...e.de>,
lsf-pc@...ts.linux-foundation.org, rust-for-linux@...r.kernel.org,
linux-block@...r.kernel.org, Matthew Wilcox <willy@...radead.org>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
open list <linux-kernel@...r.kernel.org>, gost.dev@...sung.com
Subject: Re: [RFC PATCH 00/11] Rust null block driver
On Thu, May 4, 2023 at 10:55 PM Jens Axboe <axboe@...nel.dk> wrote:
>
> 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.
But `null_blk` shouldn't be affected, no? The Rust abstractions can be
behind an explicit "experimental" / "broken" / "compile-test only"
gate (or similar) in the beginning, as a way to test how much
maintenance it actually requires.
In such a setup, Andreas could be the one responsible to keep them up
to date in the beginning. That is, in the worst case, a kernel release
could happen with the Rust side broken -- that way `null_blk` is not
impacted.
That is why a separate `MAINTAINERS` entry may be interesting if you
want to keep e.g. the `S:` level separate (though Andreas, I think,
may be able to do "Supported" at this time).
When the first real driver comes, a similar approach could be
repeated, to buy some more time too.
Cheers,
Miguel
Powered by blists - more mailing lists