Received: by 2002:a05:7412:f690:b0:e2:908c:2ebd with SMTP id ej16csp1082146rdb; Fri, 20 Oct 2023 08:01:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHkese2PWRjoDqOMltU7PP/VBtDEGco14uYC45ZDYUlkJVQEF2CUKc6fiQhNmQbst+KXCWn X-Received: by 2002:a17:90a:7066:b0:27d:4d98:6812 with SMTP id f93-20020a17090a706600b0027d4d986812mr2354554pjk.38.1697814083962; Fri, 20 Oct 2023 08:01:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697814083; cv=none; d=google.com; s=arc-20160816; b=VZzB9jLSlgYTYCmpZ1zBhg9kJR2SyrtAzZdKx6RxaLaO+2UZ/6Lcxn/jPj4GKhjWXV Zl+Vl4xGJF1UWlrEiaRMkRDRH5VggqmJNIN7ZtH64BTDyi6ayqBfmo62mbb2Djay55so nA8Z/H4pu1w4YPIni/G9WIl8hE8inYr/LMu30UGVCapS999kZ1ydubaRBMyHqZhWzdEp 9NP1bkI8zRZ0ljOMrvGG1ngEytcCpp0GvI8SEyQq4rtfHXf9htUH2XkBc8paWDDYgIkk 93eSvMMZo1R0DZ7sIb9DPISZzpudzfr8vxYE4AIZZmq5t86GWZLTSoR3fMv3/y3J16Un O5JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=RYGYs5XXTeoNP2XkujGDwK18zSEZgl2Ltx2KXN09L/Y=; fh=82XdJbyiU9ojtbH9jb2dlErJrIbqv2RmDEl/jNYuTmM=; b=lt+TiZPBSveM8aBXnAURzIrCNLXhtJ3b2N+3w4fdwMasnRmmITyxFUP/LJKc+CDzAY rJu0mwKKctmHoa2lzdRHYmZ4JViqtW8IULtdN1skkctgB4DtDm62Hd1DY6LqFcbBQFoY 3BwVzkFE3z9dHqkCYDf7r+HrqD/Xz1BRZUPX+b2w5nNwcttrb7wYSh9MrOOOm+T/qJci iqkeA4hWfwZM0gq1gqrWqCi8Bn7JALxHi6SSY9FIulIM/GH45Yypgs89PFVpihKmqQvZ pISC85IdofB22XHeik+mnA/h2hz00nqfPGCLKMuiGZqVB3Gs4lkF6/AMfSw1KA3MCrpS Z1+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=HGA+cwA5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id y1-20020a17090a86c100b00274cd766a42si4295564pjv.171.2023.10.20.08.01.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 08:01:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=HGA+cwA5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 4F436819AC68; Fri, 20 Oct 2023 08:01:17 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377643AbjJTPAl (ORCPT + 99 others); Fri, 20 Oct 2023 11:00:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377621AbjJTPAc (ORCPT ); Fri, 20 Oct 2023 11:00:32 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D847FD52; Fri, 20 Oct 2023 08:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Content-Disposition: In-Reply-To:References; bh=RYGYs5XXTeoNP2XkujGDwK18zSEZgl2Ltx2KXN09L/Y=; b=HG A+cwA59FKS0ShhrY88XTfJ/LpcVSQzq8tIHV1WGxSA1v1l31BNcd1Xa/qUhf1xo1uVC/RLp9kEmAj bO1geBIpBP9NE2N6dx/3GjhQhi+YYBy5D8He5hRACOj5OlNOhUyV1qtjVsm1Pe+2csq/wJsEME6Js n+Iz8bEbaHfQVbQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1qtqyt-002nOE-GB; Fri, 20 Oct 2023 17:00:07 +0200 Date: Fri, 20 Oct 2023 17:00:07 +0200 From: Andrew Lunn To: Miguel Ojeda Cc: Miguel Ojeda , Jonathan Corbet , Wedson Almeida Filho , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , linux-doc@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev Subject: Re: [PATCH] docs: rust: add "The Rust experiment" section Message-ID: <5c3f3ef8-e93c-49f1-881f-11c02afdaf7d@lunn.ch> References: <20231018160922.1018962-1-ojeda@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Fri, 20 Oct 2023 08:01:17 -0700 (PDT) On Wed, Oct 18, 2023 at 06:41:10PM +0200, Miguel Ojeda wrote: > On Wed, Oct 18, 2023 at 6:27 PM Andrew Lunn wrote: > > > > It very unlikely end users read this document. > > We can add a note to the Kconfig symbol too -- would that be OK with you? > > > And that statement is > > not limited to end users, it is true for everybody. > > Agreed, but that bit is meant to emphasize that end users do not have > a reason to use it at all (unlike kernel developers etc. from the > previous paragraph) > > > What we should be saying is that Rust for the Linux kernel in general > > is not ready for production use. Developing drivers in Rust is > > currently for experimentation only. Given the experimental nature of > > the work, there is some risk Rust will never be ready for production > > use. > > The risk is that Rust gets dropped from the kernel because it is not > used enough, not so much that there is a fundamental problem to solve > in order to reach production. I've talked to a small number of netdev developers, not many, but some. The general impression i get is that it is unclear what experimental actually means, and they have no idea what makes it not production ready. The two are also not necessarily mutually exclusive. To me, it appears Rust is not production ready because: You need to disable module versioning. You need to disable structure layout randomisation On X86, you need to disable X86_KERNEL_IBT and RETHUNK, both of which are part of the mitigation for speculative execution vulnerabilities So no vendor is going to release a kernel with these disabled. Networking also tends to be architecture independent, so production features need to run on X86, ARM, ARM64, and to a lesser extent MIPS, RISC-V, etc. I know this is documented, but it does not appear to be that well known within the networking community. Networking people also tend to be interested in endianness, does the code work on big endian as well as little endian? Big endian is dying out, but its not gone yet. However, with only x86 supported in mainline today, it does not seem possible to test big endian. I assume the rust type system will actually deal with this to a large extent? But are developers writing abstractions which are sound with respect to endianness? I think it would be good to describe the experiment a bit. With a multi year experiment, you often have short term goals and long term goals. What are these goals? What is the Rust for linux community trying to prove in the next few kernel cycles? What do you consider to be 4 or more cycles away? What do you consider not so important now because its not needed for your short term goals? That might also help developers understand when it will transition to production ready, but still be experimental. And you obviously need a disclaimer, Rust for Linux is a community, developers are free to scratch their own itch, so things might happen in a different order. And information like this might help get people involved, helping solve some of the limitations, spur research into different goals etc. Andrew