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 D133B28A1E6; Tue, 17 Mar 2026 08:51:44 +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=1773737505; cv=none; b=X4eQZ3ffgJGlvKHNpJY+b4JgL5JjuuzjoaLfC/WwSjpo5VG3QvTyYpRFPW7G7NdDt8BzGgMKMx/dLbsBf6Jm5DMhSpzGmpWuinC+jlzo7enZPZEyY4gmdy3C05+pp8gMV9oW883cKgqvs7zBoVs2t5eiiM8xMYZAeRRtW43s9/E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773737505; c=relaxed/simple; bh=JytjNDbTdgZKIYBWbHyUbplpWSDJLEu+0mMCHG+wBg0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o/I5HNgQQXSeo77/0iL7PswDerhKlatKyxVXVA1A6ZM2MQP4zlCIOreUiyYiPDAlf+YODAKx/UTUYUc+vy9PEpNzrIWwpJGUzWFGyumOOn0vBIxu0WDE6zDMMEaTWK1EkJkxYKDbMlmdCPeW1rXZFyHQZf3EwumadN9Omw7LusE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=QkdaLz5y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="QkdaLz5y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE7BBC4CEF7; Tue, 17 Mar 2026 08:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1773737504; bh=JytjNDbTdgZKIYBWbHyUbplpWSDJLEu+0mMCHG+wBg0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QkdaLz5yKzMj/EIimZO2VhazfCjIu2bcaWdONmsYLHuOfF3LIZ2q8Fczpv0+PPXwf jli/de/xFIq7e/VR5r6f3ZGapBpqc3+zoIBZxh8/MZmG7X4rf4wQfWb4ltQVaomxcF anzJdxgcQ6ywofNetOJyjbdXumel5uGDr2MidavE= Date: Tue, 17 Mar 2026 09:51:39 +0100 From: Greg KH To: Andreas Hindborg 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 Message-ID: <2026031730-sixties-camcorder-bf42@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> <874imesvsi.fsf@t14s.mail-host-address-is-not-set> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874imesvsi.fsf@t14s.mail-host-address-is-not-set> On Tue, Mar 17, 2026 at 09:30:05AM +0100, Andreas Hindborg wrote: > "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. That's the "penalty" for not getting your code "ready" sooner :) Seriously, don't make others do the maintenance work on these apis until you have something that you want to have merged. It's always been that way in Linux, this isn't anything new. thanks, greg k-h