Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2779556pxb; Mon, 19 Apr 2021 13:48:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRV5NGJIHV/T4QqA2lQK2iCUZR/w8qbHFCn2WDA9Phn7+WQmIsbtx0igqG7AOyhVIJch3E X-Received: by 2002:a17:90a:13c3:: with SMTP id s3mr1037442pjf.59.1618865327698; Mon, 19 Apr 2021 13:48:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618865327; cv=none; d=google.com; s=arc-20160816; b=m9O07+lvHTYltBAE998K1O8WeNeRPXPsKa+DaM0EDxcA4DpT8oBl4lrZ4EwXX4jYMC ZqV3ikQWtb1Co9YoR0BPE/Uos+gu49dfQRqGsBPqAy3+Cr/UWPvVPDsfA8FzHcPcVd/M MZ1LNqMUOtJ3I9PkJOmfMGZJ/KPMqWKRx38dnTBhwMHk2IaMXLWOCgd394+WrjaOm7GM oj36nBIfbVbiKMBKldZpFc3cmqErGoirgjMfeLCGi36EEYVJ4LviY3ieYm/W3vyCTUx4 PBddBb6xCAfhaMJFb2hRTbCsneerPjdUlrjs4vcfTcD4lOIIwjC050xIGasgOD54wCdz aDfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=EwQlx/49KXwj+9MHny3x/v1N+rlK09AXDYpt2hWs1ys=; b=1GTeJLo1Fv0SUoWO63qE7ErNXYu1/u559g20/OM90gRI9ALUcv/t3RrGA64WVInZ8x +LsOidNEIiPvpKSQ/H75RWiK55rohyLgkEd7s71MyVpQEideNXi1Qv/utbXTRaE4OHK3 ZXtocQXn9tboNwtrO3ZwgCJAcIC2Ewmxl1MWSsIDyplgCjSUN0PYuQA+POWsKMUK/gn1 ZHU56isYn05h0PO5gm1N1YQZo6cl55L1igzkbTLRJofNBXE4T89Ti2bFOSqgpNxvYX3Q revkymqQv/vqqoqy+V7liSnFNqCBQbTpDureUkRgW56GB8tP2RD/jI7p6WZmzIBJmfLG FsTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=M6Rv83Wq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u4si19921576pgo.9.2021.04.19.13.48.35; Mon, 19 Apr 2021 13:48:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=M6Rv83Wq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239522AbhDSUgn (ORCPT + 99 others); Mon, 19 Apr 2021 16:36:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234546AbhDSUgm (ORCPT ); Mon, 19 Apr 2021 16:36:42 -0400 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7F81C06138A for ; Mon, 19 Apr 2021 13:36:11 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id l22so33579345ljc.9 for ; Mon, 19 Apr 2021 13:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EwQlx/49KXwj+9MHny3x/v1N+rlK09AXDYpt2hWs1ys=; b=M6Rv83Wqxe7+zYaaVRPyzbYEby5JMD1vNERCXl3UyJGm+vbs33CGHyUTZb3aP00kzp U2fC6yirvslhroPLciAS6WwpSXmBaOSxypIINOAz7L042uh9cR4c9AZZgqeTrKczr9C7 Pv/O5Yzc+UCPzpheYm5hOUg+930cY8ytyXvCw89YKWECVc2DGPctZDGixjXZ00+AU9ym JS31bfbQ8XlO/S6cWDWQdbsEhMhiIT4NKQo9PeqDJA/HiY4sAN1UBLdpcHuuDdYPz0Y0 B7+No7u9JOyip91vsVIP9egPULZ8xdxuwltSWbeH1gu/tEnM4HzwRO8BqW1a5Ob2c263 BG5w== 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=EwQlx/49KXwj+9MHny3x/v1N+rlK09AXDYpt2hWs1ys=; b=VqiBiKxBsX1X7YHiOAfVn20+EjhgbDGqOv/Bx4g3yPmdhpvPrY1fr/D8DSOjTvcsgg cQia/8WrF67JLIEBc9vq9SMwCAFEeBdeEiq33EjDdp5LQjMYBLWlRlC5rp5fwE6wBetP kVZ+G2c4fidlxefT5cX71yd7SW+nycqFQL9o0YuAvpe0+f9v/1/VKIIFZnvpVl4pyMYc vzP+fRaP6lUVRb+y9dhiwpTWpxASJVReso5ifzjP+F7w08Vkz1yxY1ZFPDMEP5PNNFLB QRcyG1M3+i/Bjo8v65Uppe/BwxeKW3KhSIexcsUM5J9Ry5h4VLHww0u2yFLYcSa4Tcj9 SjZA== X-Gm-Message-State: AOAM532iYTSEfrIDqDxAY4GIUHCxA834YE3h93Mw/X0G2cYji5NT1Rmj y1E/JJAURprpcmzYmyb+QwNq+A1ssG5HRA5yNCDV1Q== X-Received: by 2002:a2e:988a:: with SMTP id b10mr12774742ljj.341.1618864569703; Mon, 19 Apr 2021 13:36:09 -0700 (PDT) MIME-Version: 1.0 References: <20210414184604.23473-1-ojeda@kernel.org> <20210416184713.GI4212@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: <20210416184713.GI4212@paulmck-ThinkPad-P17-Gen-1> From: Nick Desaulniers Date: Mon, 19 Apr 2021 13:35:56 -0700 Message-ID: Subject: Re: [PATCH 00/13] [RFC] Rust support To: paulmck@kernel.org, ojeda@kernel.org Cc: Boqun Feng , Peter Zijlstra , Linus Torvalds , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Alan Stern , Andrea Parri , Will Deacon , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Josh Triplett , Wedson Almeida Filho Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 16, 2021 at 11:47 AM Paul E. McKenney wrote: > > On Thu, Apr 15, 2021 at 11:04:37PM -0700, Nick Desaulniers wrote: > > On Thu, Apr 15, 2021 at 9:27 PM Boqun Feng wrote: > > > > > > But I think the Rust Community still wants to have a good memory model, > > > and they are open to any kind of suggestion and input. I think we (LKMM > > > people) should really get involved, because the recent discussion on > > > RISC-V's atomics shows that if we didn't people might get a "broken" > > > design because they thought C11 memory model is good enough: > > > > > > https://lore.kernel.org/lkml/YGyZPCxJYGOvqYZQ@boqun-archlinux/ > > > > > > And the benefits are mutual: a) Linux Kernel Memory Model (LKMM) is > > > defined by combining the requirements of developers and the behavior of > > > hardwares, it's pratical and can be a very good input for memory model > > > designing in Rust; b) Once Rust has a better memory model, the compiler > > > technologies whatever Rust compilers use to suppor the memory model can > > > be adopted to C compilers and we can get that part for free. > > > > Yes, I agree; I think that's a very good approach. Avoiding the ISO > > WG14 is interesting; at least the merits could be debated in the > > public and not behind closed doors. > > WG14 (C) and WG21 (C++) are at least somewhat open. Here are some of > the proposals a few of us have in flight: Wow, the working groups have been busy. Thank you Paul and Boqun (and anyone else on thread) for authoring many of the proposals listed below. Looks like I have a lot of reading to do to catch up. Have any of those been accepted yet, or led to amendments to either language's specs? Where's the best place to track that? My point has more to do with _participation_. Rust's RFC process is well documented (https://rust-lang.github.io/rfcs/introduction.html) and is done via github pull requests[0]. This is a much different process than drafts thrown over the wall. What hope do any kernel contributors have to participate in the ISO WGs, other than hoping their contributions to a draft foresee/address any concerns members of the committee might have? How do members of the ISO WG communicate with folks interested in the outcomes of their decisions? The two processes are quite different; one doesn't require "joining a national body" (which I assume involves some monetary transaction, if not for the individual participant, for their employer) for instance. (http://www.open-std.org/jtc1/sc22/wg14/www/contributing which links to https://www.iso.org/members.html; I wonder if we have kernel contributors in those grayed out countries?) It was always very ironic to me that the most important body of free software was subject to decisions made by ISO, for better or for worse. I would think Rust's RFC process would be more accessible to kernel developers, modulo the anti-github crowd, but with the Rust's community's values in inclusion I'm sure they'd be happy to accomodate folks for the RFC process without requiring github. I'm not sure ISO can be as flexible for non-members. Either way, I think Rust's RFC process is something worth adding to the list of benefits under the heading "Why Rust?" in this proposed RFC. > > P2055R0 A Relaxed Guide to memory_order_relaxed > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2055r0.pdf > P0124R7 Linux-Kernel Memory Model (vs. that of C/C++) > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0124r7.html > P1726R4 Pointer lifetime-end zap > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1726r4.pdf > https://docs.google.com/document/d/1MfagxTa6H0rTxtq9Oxyh4X53NzKqOt7y3hZBVzO_LMk/edit?usp=sharing > P1121R2 Hazard Pointers: Proposed Interface and Wording for Concurrency TS 2 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1121r2.pdf > P1382R1 volatile_load and volatile_store > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1382r1.pdf > P1122R2 Proposed Wording for Concurrent Data Structures: Read-Copy-Update (RCU) > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1122r2.pdf > https://docs.google.com/document/d/1MfagxTa6H0rTxtq9Oxyh4X53NzKqOt7y3hZBVzO_LMk/edit?usp=sharing > P0190R4 Proposal for New memory order consume Definition > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf > P0750R1 Consume > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html Does wg14 not participate in these discussions? (Or, is there a lot of overlap between participants in both?) http://93.90.116.65/JTC1/SC22/WG14/www/docs/ seems like a list of proposals and meeting minutes, but all of the above links look like WG21. The model of decisions being made for C++ then trickling down to C is definitely curious. Though perhaps for the topics of memory orderings there's enough overlap between the two languages for it not to matter. > > P1726R4 is of particular concern, along with consume. [0] You can see all of the existing ones here: https://github.com/rust-lang/rfcs/tree/master/text, with links to discussions for each on github. (Here's one that has not been accepted yet: https://github.com/rust-lang/rfcs/blob/master/text/1937-ques-in-main.md, see the link to the issue in the rust issue tracker has lots of comments _from the community_: https://github.com/rust-lang/rust/issues/43301). I guess the equivalents for the ISO WGs would be the meeting minutes? -- Thanks, ~Nick Desaulniers