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 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 E2F3CC433B4 for ; Mon, 26 Apr 2021 00:31:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A932461176 for ; Mon, 26 Apr 2021 00:31:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231422AbhDZAcU (ORCPT ); Sun, 25 Apr 2021 20:32:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231247AbhDZAcT (ORCPT ); Sun, 25 Apr 2021 20:32:19 -0400 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAD6DC061760 for ; Sun, 25 Apr 2021 17:31:38 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id o16so62015221ljp.3 for ; Sun, 25 Apr 2021 17:31:38 -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=xiJzJOLdknIj0RBYTk/1dN6htHjhW+TONZdztDGFbBU=; b=Jdq7oZq6fxDOqg46MRmtQhPd4SrRlEoVknjUuOCN8BcuzP0XNt6vzVqFCgtk1RQnDo aoNcId528WptBW8I/GRW0hTa2aXzAWWFwChG0KT+nxIMCls5G27DWJ1JE6OnT+o+2yLV aQqNBLsysaitWjvDbKKJq91G8PTL4sGca2FUlg4KbpmK5vpAvTqmOQ/bOFj6yLDG/9mg xjcfvDF0r9YdV+2/oWeKiDvthYWFkTUor+1dsPncf5EHnm3RR1SVKQAGE8Nxv0eVODnN kn5XxNw2deklLmJjDafIhLdW0X2KtTmQhB1X51MPIrl0AaDBNZ16CsRhDmLQ7Rh7W3o8 lesQ== 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=xiJzJOLdknIj0RBYTk/1dN6htHjhW+TONZdztDGFbBU=; b=TU2AGBLe4o8jRPqUEhKlsrgNga98Fv3EKDTbOBTiJLlIE6ZPqxwijhoemSElIoS7rp 84aui33TyVaZtCbDYZxFCwIb3De7YfBkSrWAZhnmQMGQDO9iW96wD53iT161+8tpIFys out/0r1lZ2bW4Y/f8Ol+QDqMtBvp9ipJTzQTq6JKBvpXUbBRkcFqQhVDjsZK1o9HuTTk 4frFGOdD46QvFQ7aIJoYJiuoA2k93VVupUZXoCSafrUmDeWmjZPzq52cgsukQjISL7JV c8wKHImnKQ/jxaCDJtOsU4Bo1LMNRidn+N+ZBEtdbjX9sFgVTzcfjeDM/GYDeOQacdL5 L5MQ== X-Gm-Message-State: AOAM531ZhjHG1dMG05xC35qWrMpVveRxKWyxfqFFch0anHB92TqRYkSy Dkyt4UsaR1J9+iODSkUuqbgS7zhJ6RXQUNlZdHUKTw== X-Google-Smtp-Source: ABdhPJzMJggL0ZBTNgft14ZUf0CVG/24WpdjGgjRupl3gpl/UhKK6SN9IOAxYxBKJAnZm1R2/rMVeGJ9kPNWkYsj1cE= X-Received: by 2002:a2e:a54c:: with SMTP id e12mr11354812ljn.326.1619397097310; Sun, 25 Apr 2021 17:31:37 -0700 (PDT) MIME-Version: 1.0 References: <20210414184604.23473-1-ojeda@kernel.org> In-Reply-To: From: Linus Walleij Date: Mon, 26 Apr 2021 02:31:26 +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 Thu, Apr 22, 2021 at 11:29 PM Miguel Ojeda wrote: > > But as subsystem maintainer I'd like a clear picture of this wrapper > > overhead, what does it usually entail? A typical kernel API has > > vtable and a few variables, not much more than that. > > If you mean runtime-overhead, i.e. performance, it should be very > small or even zero. It should be possible to perform LTO across > languages too. > > If you mean source code overhead, or cognitive overhead, then it is > quite a bit, yes. Please see below. Yeah that is what I mean :) > I hear you! I do not think it will take decades for kernel developers > to get up to speed, but I agree that having some help/backup is a very > good idea in the beginning. > > Our hope is that, if Rust advantages prove themselves, then it will > the subsystem maintainers the ones that will want to create and > maintain the wrappers so that drivers in their tree are easier to > maintain and less prone to mistakes ;-) I am not really convinced that (leaf) drivers is where Rust will help most. As I mentioned in my mail to Wedson that I think things like network protocols that deal with abstract entities will have more "pure code" (not deal with machine registers, just RAM memory). File systems would be another example. 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. After all fixing that compiler support is an insignificant amount of work compared to what Rust in the core kernel will be. Yours, Linus Walleij