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 2A81D34F24E; Tue, 17 Mar 2026 08:30:21 +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=1773736221; cv=none; b=YTq/5Ic+4ZO88qgl53sB/naeFBoaTYVJivqdTd4FxzrTBuThH9MPYuKn8gqHsS5OM7X5kQoIcxqPT3vQ6CmpEyen1t5W8E+hHd5afefhSCaa5iyaP7iPnyIYgz22rdzpp/Gn0iKNJGegUPDLmxW/Ja37uvvO3qaWRj8gYKuNvls= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773736221; c=relaxed/simple; bh=oIBVvLVbzPMufSL53/fAAYNBUM75OfSaGp87BvjBez8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=MIPNqN9NPxvEPH/BJ/riFW2EUZznIu3oOvmMZVikvDTgjOdMVWbWmQqn2G++sFTZLj8YurG6goQOw8BYR5ZtPitcxriEfQBc7Hz3Wekg59+/q29or0PpfsIZoHNhPUlq0OvwHfGD24OCUo/2aGTtDmaN1Cwd3OJDNHIrZwqf/MY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I5ojFWhH; 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="I5ojFWhH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FDEEC4CEF7; Tue, 17 Mar 2026 08:30:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773736220; bh=oIBVvLVbzPMufSL53/fAAYNBUM75OfSaGp87BvjBez8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I5ojFWhHsxKXGuAhRFJ/jFCyn5Qw1QeQCsMD6874uowcIbNNc4KYwhm8nMj2Q8v0S SAkwWGTeyDyGD2/tvX21yxFuJaaIfbZs9PCs9z5h9jlrtzs/l2dVugceV6lhVZe7TJ S8H1zO/upTBZ26NLAch//KKTs+1R0brHu4uNJ96QW13y9GkpgMtmP6dzmxmmvpR8M7 wS655ALSA6GAB/fPH/KAuXYOt/ojvqJVvgEtw539gNQq4aSXl1uFG/v3/jDZON18Dg ZPUtkyZJHLf67Wi33zwqiRO8PT5CEARnphQcX9kcxJlMlLQx26MlrShoRRcPisUiiG EnxKW4BfZ1vJg== From: Andreas Hindborg To: Greg KH Cc: Hannes Reinecke , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org, Bart Van Assche , Chaitanya Kulkarni , Damien Le Moal , Daniel Gomez , Hans Holmberg , Jan Kara , Johannes Thumshirn , John Pittman , John Stultz , "Martin K. Petersen" , Miguel Ojeda , Ming Lei , Niklas Cassel , Nitesh Shetty , Oliver Mangold , Pankaj Raghav , Shin'ichiro Kawasaki , Theodore Tso , Wedson Almeida Filho , gost.dev@samsung.com, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [LSF/MM/BPF TOPIC][RESEND] Status of Rust in the block subsystem In-Reply-To: <2026031706-simile-cornball-7744@gregkh> References: <878qcpbux5.fsf@kernel.org> <87ikb2mrib.fsf@t14s.mail-host-address-is-not-set> <7a4dfa82-41af-401f-aa92-5bd19fe6f654@suse.de> <87a4w6swup.fsf@t14s.mail-host-address-is-not-set> <_GaL00txVaF_Sjyfl2GBXOxmALDBVv79LLeKGF5q6AEczDDrzeikvRn3a2ZMXSldlNCa2czJP_YOVEKOuP-MbQ==@protonmail.internalid> <2026031706-simile-cornball-7744@gregkh> Date: Tue, 17 Mar 2026 09:30:05 +0100 Message-ID: <874imesvsi.fsf@t14s.mail-host-address-is-not-set> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Greg KH" writes: > On Tue, Mar 17, 2026 at 09:07:10AM +0100, Andreas Hindborg wrote: >> "Hannes Reinecke" writes: >> >> > On 3/17/26 00:51, Keith Busch wrote: >> >> On Wed, Mar 11, 2026 at 02:21:00PM +0100, Andreas Hindborg wrote: >> >>> As this topic was not selected for discussion at LSF, and I did not >> >>> receive an invitation for LSF this year, I propose that we discuss these >> >>> two topics on list. >> >>> >> >>> I do believe that these topics need to be discussed, and I would very >> >>> much appreciate your input. >> >> >> >> I can sympathise the difficulty of maintaining external modules. >> >> >> >> In terms of this being a reference driver, that implies some future >> >> hardware driver may leverage this for its development. Is there anything >> >> in mind at this point for production? If so, maybe that use case should >> >> take the lead. But either way, I think rust-nvme upstream inclusion >> >> would invite confusion. Once it's upstream, it's no longer a reference >> >> when distros and users turn it on. >> >> >> > I wholeheartedly agree. >> > >> > While I do see the original appeal to have a rust-nvme driver, having >> > one will just lead to confusion on all sides, especially for distros. >> > (Why is it there? should it be preferred to the original one? Do we >> > have to support both of them? Are there features missing in either >> > of these drivers?) >> > In general we are trying hard to avoid duplication in the linux kernel, >> > especially on the driver side. We constantly have to fight^Wargue >> > with driver vendors why duplicating existing drivers to support new >> > hardware is a bad idea, so we really should not start now just because >> > the driver is written in another language. >> > (That really might be giving vendors bad ideas :-) >> >> I actually agree to some extent. But I do think we can get around most >> confusion with loud and clear documentation. We could make the driver >> not probe by default, requiring a configfs setting to probe. Or leave >> the PCI identifier table empty, so patching the driver is required to >> make it probe. >> >> For me, the big benefit would be having the rust nvme driver as part of >> an allmodconfig or allyesconfig. That would prevent a ton of trouble. >> >> We do plan to utilize the block infrastructure, but I think we are still >> quite a long way from sending anything. Keeping the rust nvme driver in >> tree till that point would prevent pci, dma, irq, etc. from developing >> in ways that would not support a block device use case. As an example, >> upstream Rust irq APIs are not actually able to support NVMe at the >> moment. They work fine for GPU drivers though. And I cannot go an fix >> them without a user. Same for DMA pool. >> >> I could go and find some other piece of unsupported PCI hardware and >> write a driver for that, use that to keep the APIs in shape upstream. >> It's just a lot more work and the NVMe driver is already here and 90% >> ready. > > This implies that there really is no "need" for these rust bindings at > all, if you don't know of, or are planning for, any real driver for > them. So why have them at all? > > For the PCI and driver core bindings, and the majority of the other ones > merged, we have real users (binder, nova-core, etc.) and so we are > willing to take them and keep them up to date. For these block > bindings, why is it even worth it to have them around if there's never > going to be a real user? I'm just going to quote myself in case you missed these few sentences: We do plan to utilize the block infrastructure, but I think we are still quite a long way from sending anything. My fear is that by then, I have to patch a number of GPU drivers in the process. Best regards, Andreas Hindborg