LKML Archive on lore.kernel.org
 help / color / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: ojeda@kernel.org, Boqun Feng <boqun.feng@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alan Stern <stern@rowland.harvard.edu>,
	Andrea Parri <parri.andrea@gmail.com>,
	Will Deacon <will@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	Akira Yokosawa <akiyks@gmail.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Wedson Almeida Filho <wedsonaf@google.com>
Subject: Re: [PATCH 00/13] [RFC] Rust support
Date: Mon, 19 Apr 2021 14:37:15 -0700
Message-ID: <20210419213715.GD975577@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <CAKwvOdkpOZk-FXJ0iOLvhyQr7wVcWwzgc0gk_8KTtOfF_Q8Q3g@mail.gmail.com>

On Mon, Apr 19, 2021 at 01:35:56PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 16, 2021 at 11:47 AM Paul E. McKenney <paulmck@kernel.org> 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 <boqun.feng@gmail.com> 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.

And this is only the proposals relating to low-level concurrency.
There are way more proposals relating to vector processing, GPGPUs,
task-based concurrency, and so on.  Here is the list of papers submitted
thus far this year:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/

> Have any of those been accepted yet, or led to amendments to either
> language's specs?  Where's the best place to track that?

None of them have yet to be accepted.  P1121R2 has been recommended for
Concurrency Technical Specification 2, which is a stepping stone to the
International Standard.  I hope that P1122R2 will follow soon.

> 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?

I participate in ISO SC22 WG21 (C++) and to a lesser extent WG14 (C).
Participation is key.  The various US National Laboratories send quite a
few people, which has a lot to do with these two standards accommodating
their wishes.

> 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?)

Your employer is already a member of WG21 (C++), so there is no ISO
obstacle to participation by you or by your colleagues.  If you contact
me offlist, I would be happy to connect you to your employer's WG21
representative.

> 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.

Being a member is not all that necessary.  Yes, at the end of the day,
only national bodies can formally vote, but I have not come across a
case of anyone being barred from discussions, paper submissions, or straw
polls (informal votes used to set direction) due to not being a member.
Given that the national bodies are only permitted to comment on and vote
on finished proposals, you can argue that individuals have more influence.

Similarly, it is not necessary to be personally acquainted with me in
order to get patches into Linux-kernel RCU.

> 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.

Comparing Rust's process to that of the C or C++ standard committees is
best done by someone who understands both, and that set does not appear
to include either you or me.  ;-)

I could easily believe that Rust's process is lighter weight, but on
the other hand, I doubt that Rust's definition has legal standing in
any jurisdiction just yet.

> > 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<T> and volatile_store<T>
> >         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.

Back in 2005, WG14 and WG21 agreed that low-level concurrency proposals
would be handled by WG21, and that WG14 members would participate.
But some things required working with both committees, for example,
there is a WG14 counterpart to P1726R4, namely N2443:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2443.pdf

> > 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?

There are minutes on wikis, github issue trackers, follow-on papers,
and so on.

Once things are reasonably well set for a given proposal, the formal
national-body-level processes take over.  I have been happy to be able
to sit out that phase for the most part.  ;-)

							Thanx, Paul

  reply index

Thread overview: 187+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 18:45 ojeda
2021-04-14 18:45 ` [PATCH 01/13] kallsyms: Support "big" kernel symbols (2-byte lengths) ojeda
2021-04-14 19:44   ` Matthew Wilcox
2021-04-14 19:59     ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 02/13] kallsyms: Increase maximum kernel symbol length to 512 ojeda
2021-04-14 23:48   ` Nick Desaulniers
2021-04-14 18:45 ` [PATCH 03/13] Makefile: Generate CLANG_FLAGS even in GCC builds ojeda
2021-04-14 18:59   ` Nathan Chancellor
2021-04-15 10:18     ` Miguel Ojeda
2021-04-14 23:46   ` Nick Desaulniers
2021-04-15  0:47     ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 04/13] Kbuild: Rust support ojeda
2021-04-14 23:19   ` Nick Desaulniers
2021-04-15  0:43     ` Miguel Ojeda
2021-04-15 18:03       ` Nick Desaulniers
2021-04-16 12:23         ` Miguel Ojeda
2021-04-17 19:35       ` Masahiro Yamada
2021-04-16 13:38   ` Peter Zijlstra
2021-04-16 17:05     ` Linus Torvalds
2021-04-16 17:47       ` Miguel Ojeda
2021-04-16 18:09         ` Al Viro
2021-04-16 18:57           ` Miguel Ojeda
2021-04-16 20:22             ` Willy Tarreau
2021-04-16 20:34               ` Connor Kuehl
2021-04-16 20:58                 ` Willy Tarreau
2021-04-16 21:39                   ` Miguel Ojeda
2021-04-16 22:04                     ` Willy Tarreau
2021-04-16 22:45                       ` Al Viro
2021-04-16 23:46                       ` Miguel Ojeda
2021-04-17  4:24                         ` Willy Tarreau
2021-04-17 15:38                           ` Miguel Ojeda
2021-04-16 21:19               ` Miguel Ojeda
2021-04-16 17:34     ` Miguel Ojeda
2021-04-19 19:58       ` David Sterba
2021-04-19 20:17         ` Matthew Wilcox
2021-04-19 21:03           ` Miguel Ojeda
2021-04-19 20:54         ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 05/13] Rust: Compiler builtins crate ojeda
2021-04-14 19:19   ` Linus Torvalds
2021-04-14 19:34     ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 06/13] Rust: Module crate ojeda
2021-04-14 18:45 ` [PATCH 07/13] Rust: Kernel crate ojeda
2021-04-14 19:31   ` Linus Torvalds
2021-04-14 19:50     ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 08/13] Rust: Export generated symbols ojeda
2021-04-14 18:46 ` [PATCH 09/13] Samples: Rust examples ojeda
2021-04-14 19:34   ` Linus Torvalds
2021-04-14 19:42     ` Miguel Ojeda
2021-04-14 19:49       ` Matthew Wilcox
2021-04-16 11:46       ` Andrej Shadura
2021-04-14 23:24     ` Nick Desaulniers
2021-04-15  7:10       ` Greg Kroah-Hartman
2021-04-15  7:39         ` Nick Desaulniers
2021-04-15 12:42         ` Miguel Ojeda
2021-04-16 13:07         ` Sven Van Asbroeck
2021-04-16 13:20           ` Greg Kroah-Hartman
2021-04-14 18:46 ` [PATCH 10/13] Documentation: Rust general information ojeda
2021-04-14 22:17   ` Nick Desaulniers
2021-04-14 23:34     ` Miguel Ojeda
2021-04-14 18:46 ` [PATCH 11/13] MAINTAINERS: Rust ojeda
2021-04-14 21:55   ` Nick Desaulniers
2021-04-14 22:02     ` Miguel Ojeda
2021-04-14 22:36   ` Nick Desaulniers
2021-04-14 18:46 ` [PATCH 12/13] Rust: add abstractions for Binder (WIP) ojeda
2021-04-14 18:46 ` [PATCH 13/13] Android: Binder IPC in Rust (WIP) ojeda
2021-04-14 19:44 ` [PATCH 00/13] [RFC] Rust support Linus Torvalds
2021-04-14 20:20   ` Miguel Ojeda
2021-04-15  1:38     ` Kees Cook
2021-04-15  8:26       ` David Laight
2021-04-15 18:08         ` Kees Cook
2021-04-15 12:39       ` Miguel Ojeda
2021-04-14 20:09 ` Matthew Wilcox
2021-04-14 20:21   ` Linus Torvalds
2021-04-14 20:35     ` Josh Triplett
2021-04-14 22:08     ` David Laight
2021-04-14 20:29   ` Miguel Ojeda
2021-04-18 15:31   ` Wedson Almeida Filho
2021-04-15  0:22 ` Nick Desaulniers
2021-04-15 10:05   ` Miguel Ojeda
2021-04-15 18:58 ` Peter Zijlstra
2021-04-16  2:22   ` Wedson Almeida Filho
2021-04-16  4:25     ` Al Viro
2021-04-16  5:02       ` Wedson Almeida Filho
2021-04-16  5:39         ` Paul Zimmerman
2021-04-16  7:46         ` Peter Zijlstra
2021-04-16  7:09     ` Peter Zijlstra
2021-04-17  5:23       ` comex
2021-04-17 12:46       ` David Laight
2021-04-17 14:51       ` Paolo Bonzini
2021-04-19  7:32         ` Peter Zijlstra
2021-04-19  7:53           ` Paolo Bonzini
2021-04-19  8:26             ` Peter Zijlstra
2021-04-19  8:35               ` Peter Zijlstra
2021-04-19  9:02               ` Paolo Bonzini
2021-04-19  9:36                 ` Peter Zijlstra
2021-04-19  9:40                   ` Paolo Bonzini
2021-04-19 11:01                     ` Will Deacon
2021-04-19 17:14                   ` Linus Torvalds
2021-04-19 18:38                     ` Paolo Bonzini
2021-04-19 18:50                       ` Linus Torvalds
2021-04-22 10:03     ` Linus Walleij
2021-04-22 14:09       ` David Laight
2021-04-22 15:24       ` Wedson Almeida Filho
2021-04-26  0:18         ` Linus Walleij
2021-04-26 14:26           ` Miguel Ojeda
2021-04-26 14:40           ` Wedson Almeida Filho
2021-04-26 16:03             ` Miguel Ojeda
2021-04-27 10:54             ` Linus Walleij
2021-04-27 11:13               ` Robin Randhawa
2021-04-29  1:52               ` Wedson Almeida Filho
2021-04-26 18:01           ` Miguel Ojeda
2021-04-22 21:28       ` Miguel Ojeda
2021-04-26  0:31         ` Linus Walleij
2021-04-26 18:18           ` Miguel Ojeda
2021-04-27 11:13             ` Linus Walleij
2021-04-28  2:51               ` Kyle Strand
2021-04-28  3:10               ` Miguel Ojeda
2021-05-04 21:21                 ` Linus Walleij
2021-05-04 23:30                   ` Miguel Ojeda
2021-05-05 11:34                     ` Linus Walleij
2021-05-05 14:17                       ` Miguel Ojeda
2021-05-05 15:13                         ` Enrico Weigelt, metux IT consult
2021-05-06 12:47                         ` Linus Walleij
2021-05-07 18:23                           ` Miguel Ojeda
2021-04-16  4:27   ` Boqun Feng
2021-04-16  6:04     ` Nick Desaulniers
2021-04-16 18:47       ` Paul E. McKenney
2021-04-19 20:35         ` Nick Desaulniers
2021-04-19 21:37           ` Paul E. McKenney [this message]
2021-04-19 22:03           ` Miguel Ojeda
2021-04-16 20:48     ` Josh Triplett
2021-04-16  8:16   ` Michal Kubecek
2021-04-16  9:29     ` Willy Tarreau
2021-04-16 11:24 ` Peter Zijlstra
2021-04-16 13:07   ` Wedson Almeida Filho
2021-04-16 14:19     ` Peter Zijlstra
2021-04-16 15:04       ` Miguel Ojeda
2021-04-16 15:43         ` Peter Zijlstra
2021-04-16 16:21           ` Miguel Ojeda
2021-04-16 15:33       ` Wedson Almeida Filho
2021-04-16 16:14         ` Willy Tarreau
2021-04-16 17:10           ` Miguel Ojeda
2021-04-16 17:18             ` Peter Zijlstra
2021-04-16 18:08               ` Matthew Wilcox
2021-04-17 11:17                 ` Peter Zijlstra
2021-04-17 11:46                   ` Willy Tarreau
2021-04-17 14:24                     ` Peter Zijlstra
2021-04-17 14:36                       ` Willy Tarreau
2021-04-17 13:46                   ` David Laight
2021-04-16 17:37             ` Willy Tarreau
2021-04-16 17:46               ` Connor Kuehl
2021-04-20  0:24               ` Nick Desaulniers
2021-04-20  3:47                 ` Willy Tarreau
2021-04-20  5:56                 ` Greg Kroah-Hartman
2021-04-20  6:16                   ` Willy Tarreau
2021-04-29 15:38                     ` peter enderborg
2021-04-17 13:53           ` Wedson Almeida Filho
2021-04-17 14:21             ` Willy Tarreau
2021-04-17 15:23               ` Miguel Ojeda
2021-04-18 15:51               ` Wedson Almeida Filho
2021-04-17 12:41       ` David Laight
2021-04-17 13:01         ` Wedson Almeida Filho
2021-04-16 15:03     ` Matthew Wilcox
2021-04-17 13:29       ` Wedson Almeida Filho
2021-04-16 15:58     ` Theodore Ts'o
2021-04-16 16:21       ` Wedson Almeida Filho
2021-04-17 15:11       ` Paolo Bonzini
2021-04-16 14:21   ` Miguel Ojeda
2021-04-17 20:42 ` Richard Weinberger
2021-04-28 18:34 ` Mariusz Ceier
2021-04-28 20:25   ` Nick Desaulniers
2021-04-28 21:21   ` David Laight
2021-04-29 11:14     ` Kajetan Puchalski
2021-04-29 11:25   ` Kajetan Puchalski
2021-04-29 14:06     ` Mariusz Ceier
2021-04-29 14:13       ` Sven Van Asbroeck
2021-04-29 14:26         ` Willy Tarreau
2021-04-29 15:06       ` Al Viro
2021-04-29 16:09         ` Mariusz Ceier
2021-04-30  6:39     ` Thomas Schoebel-Theuer
2021-04-30  8:30       ` David Laight
2021-05-05 13:58       ` Enrico Weigelt, metux IT consult
2021-05-05 14:41         ` Miguel Ojeda
2021-04-29  5:20 Mariusz Ceier
2021-04-29  5:21 Mariusz Ceier
2021-04-29  8:18 ` David Laight
2021-07-30 23:22 Dillan Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210419213715.GD975577@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=akiyks@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=ndesaulniers@google.com \
    --cc=npiggin@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=parri.andrea@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=wedsonaf@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git