Date: Thu, 14 Mar 2024 10:03:28 -0700
From: Bart Van Assche <bvanassche@....org>
To: Philipp Stanner <pstanner@...hat.com>, Andreas Hindborg
 <nmi@...aspace.dk>, Jens Axboe <axboe@...nel.dk>,
 Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>,
 Damien Le Moal <Damien.LeMoal@....com>, Hannes Reinecke <hare@...e.de>,
 "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Cc: Andreas Hindborg <a.hindborg@...sung.com>,
 Niklas Cassel <Niklas.Cassel@....com>, Greg KH <gregkh@...uxfoundation.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>, Alice Ryhl <aliceryhl@...gle.com>,
 Chaitanya Kulkarni <chaitanyak@...dia.com>,
 Luis Chamberlain <mcgrof@...nel.org>, Yexuan Yang <1182282462@...t.edu.cn>,
 Sergio González Collado <sergio.collado@...il.com>,
 Joel Granados <j.granados@...sung.com>,
 "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>,
 Daniel Gomez <da.gomez@...sung.com>, open list
 <linux-kernel@...r.kernel.org>,
 "rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
 "lsf-pc@...ts.linux-foundation.org" <lsf-pc@...ts.linux-foundation.org>,
 "gost.dev@...sung.com" <gost.dev@...sung.com>
Subject: Re: [RFC PATCH 0/5] Rust block device driver API and null block
 driver

On 3/14/24 05:14, Philipp Stanner wrote:
> On Wed, 2024-03-13 at 11:02 -0700, Bart Van Assche wrote:
>> On 3/13/24 04:05, Andreas Hindborg wrote:
>>> This is the second version of the Rust block device driver API and
>>> the Rust null
>>> block driver. The context and motivation can be seen in cover
>>> letter of the RFC
>>> v1 [1]. If more context is required, a talk about this effort was
>>> recorded at
>>> LPC [2]. I hope to be able to discuss this series at LSF this year
>>> [3].
>>
>> Memory safety may land in C++ in the near future (see also
>> https://herbsutter.com/2024/03/). If memory-safe C++ or memory-safe C
>> would be adopted in the kernel, it would allow writing memory-safe
>> drivers without having to add complicated bindings between existing C
>> code and new Rust code.
> 
> Correct, but it would also most likely allow to just arbitrarily ignore
> the "modern, memory safe C" (or C++) and write it the old way.

Linux kernel developers have the choice today between memory-unsafe C
and memory-safe Rust so they already have the freedom to ignore memory
safety by choosing for C. In my opinion a compiler option should be
introduced once memory-safe C or C++ is available that can be set per
source file and that makes the build fail for source files that
unintentionally do not follow the memory-safety rules.

> The Kernel's C already has more memory safety than standardized C:
> There's devres, and since last year there's the __cleanup attribute.
> – but the thing is, you can just ignore it and do it the old way.

devres is controversial - see also Laurent Pinchart, "Why is
devm_kzalloc() harmful and what can we do about it", LPC, 2022
(https://lpc.events/event/16/contributions/1227/).

> One of the stronger arguments behind the push for Rust is that the
> language by design forces you to obey, because otherwise the compiler
> will just reject building.

Rust has a very significant disadvantage that memory-safe C/C++ won't
have: supporting Rust means adding Rust bindings for all C functions
called from Rust code. This forces everyone who wants to change an
interface to also change the Rust bindings and hence will make it
harder to maintain the Linux kernel in its entirety.

Thanks,

Bart.

Powered by blists - more mailing lists