From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E35AC43460 for ; Tue, 27 Apr 2021 11:13:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C4A5D613D8 for ; Tue, 27 Apr 2021 11:13:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235815AbhD0LOb (ORCPT ); Tue, 27 Apr 2021 07:14:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235808AbhD0LOa (ORCPT ); Tue, 27 Apr 2021 07:14:30 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1965C061574 for ; Tue, 27 Apr 2021 04:13:44 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id z13so12096017lft.1 for ; Tue, 27 Apr 2021 04:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+6WzqLyiZKhKSJY8jYMrMfFwc4Ih1W7DjlWwozGabCA=; b=q1CvhHPZNPCzVXL+eN0+T90/rhrNDTEGeHe0B9InduoF98HXZ6LvqT0k/KkdpQhaed EYTaQylYZdyTkkqgz1fD49HC52aY9k9EJf4jB0FqIG89QyCOUF9XRzT+M++d0Cnb39Rh cERREkzpk5nPIwbUX2eUYtB75RizCNOSQ896EJJ2dNqVDg747j3Nn5a68phBMPu2GTcd chMdUwv/6hDnvWVYJsH1UkfAW8BtT/e+NlHC9v7cVHhQXItZQ5eWD5KtWIDlXvjhIDDs mLcouHkC4aPS0K3xk7ziJjNRwL5appkAd96MP7kBEHe92sm0TzjbPiTYodF3zQleS9mF FJkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+6WzqLyiZKhKSJY8jYMrMfFwc4Ih1W7DjlWwozGabCA=; b=I3V3zLrCFGWPEdI8AM014K865CO58CGOQD8tkQ/Z9WnEKHtWkjP6YEPeEyYO0lDfLy XaLerZj1CsyZkXm5iZiECUWBICSGPEYSZqRc02lb7WeBuQNOYQmNIzoaWZhXrkNI9KM0 xgt/vEq3SBleHcWIKZKzmv9YaVhxcY+dp12tKb1Gd5hBAqJoVxJu+H234WqfU+WdG2Gk 9EoMrjscHFBV5GpY96MlRMpI623PyMzM98tT07pzoFWKjSKjP+pJBqAzDU7fxwJFl/ux D3QxMMI3I5eY8UFwMXHyPA/HUIN0fea6YOqWecM5feabY/gIBDjxkgKoimuwJJq2zaAT oRCg== X-Gm-Message-State: AOAM530jd2lvx8NnztqIm24s/AjVQOFvKdQvR227iyBg1b9brS1ErOWV D6UFvu85yHM6LICNPeQ5fqMU4bcR3ry/lgzxlTv+NQ== X-Google-Smtp-Source: ABdhPJyq8TnYEmj5N3TDgDxEQ+7LEfs//gKfhBfewYP5TgeLHDcSCnq84n3Chlc6Zy3MWdsTAjYGHoh8vOWMSYDErMA= X-Received: by 2002:a19:c218:: with SMTP id l24mr16789090lfc.529.1619522022816; Tue, 27 Apr 2021 04:13:42 -0700 (PDT) MIME-Version: 1.0 References: <20210414184604.23473-1-ojeda@kernel.org> In-Reply-To: From: Linus Walleij Date: Tue, 27 Apr 2021 13:13:31 +0200 Message-ID: Subject: Re: [PATCH 00/13] [RFC] Rust support To: Miguel Ojeda Cc: Wedson Almeida Filho , Peter Zijlstra , Miguel Ojeda , Linus Torvalds , Greg Kroah-Hartman , rust-for-linux , linux-kbuild , Linux Doc Mailing List , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org On Mon, Apr 26, 2021 at 8:18 PM Miguel Ojeda wrote: > On Mon, Apr 26, 2021 at 2:31 AM Linus Walleij wrote: > > > > I think the Rust proponents should be open to the fact that their > > work will eventually depend on themselves or someone else > > fixing a working compiler for the maintained architectures in > > the Linux kernel one way or the other, so they will be able to > > work with Rust project anywhere in the kernel. > > > > For example m68k is not going away. Avoiding this question > > of compiler support, just waiting and hoping that these old > > architectures will disappear is the wrong idea. The right idea > > is to recognize that LLVM and/or GCC Rust needs to > > support all these architectures so they can all use Rust. > > Someone needs to put in the effort. > > The RFC does not avoid the question -- please note it explicitly > mentions the architecture/platform support issue and the current > dependency on LLVM, as well as the possible ways to solve it. OK true. Sorry for being sloppy. Actually my reply to Wedson brought up a new issue, which is the quality of learning resources and the lack of an equivalent to The C Programming Language book. > But even if we did not have the issue today, it seems like starting > with drivers and other "leaf" modules is a better approach. There are > several reasons: > > - If for reason reason we wanted to remove Rust from the kernel, > then it would be easier to do so if only "leaf" bits had been written. > > - We cannot compile the Rust support without nightly features yet, > so it does not seem wise to make it a hard requirement right away. > > - Kernel developers need time to learn a bit of Rust, thus writing > subsystems or core pieces of the kernel in Rust would mean less people > can understand them. > > Given that drivers are a big part of the new code introduced every > release, that they are "leaf" modules and that in some cases they are > only intended to be used with a given architecture, they seem like a > good starting point. I'm not sure I agree with this. I think a good starting point would be to either fix Rust support in GCC or implement some more important ISAs in LLVM, whichever is easiest. I don't mind having just *one* compiler but I mind having *a* compiler for every arch we support. The situation for LLVM is very well described in the Wikipedia entry for LLVM: "but most of this hardware is mostly obsolete, and LLVM developers decided the support and maintenance costs were no longer justified" - this is what I would call deprecationism (deletionism). I think this is a detrimental force for both compilers and kernels. It encourages developers of compilers and kernels to do the wrong thing: instead of rewriting their compiler and kernel infrastructure such that maintenance of older ISAs and architectures becomes a bliss they do what mathematicians do "let's assume a simpler version of the problem". And this results in a less versatile infrastructure and less adaptable code in the end. Which will affect how agile and adaptive the software is. And when something new comes along it hits you in the head. Portability to old systems and ISAs is a virtue in itself because of the effect it has on code quality, not necessarily for the support itself. Deprecationism is more the side effect of a certain business strategy to toss new technology out every quarter without having to care about aftermarket or postmarket too much. This irritates people to the extent that there is now even a project called "PostmarketOS" (Linux based). It is not sustainable to use an emotional argument, but that is really not my point, I care about code quality and diversity of ISAs and target systems improves code quality in my book. I might be an extremist, but I do need to state this point. Yours, Linus Walleij