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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DC3F9C27C53 for ; Wed, 19 Jun 2024 15:00:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hSe7xh6KAt4sne8yLQr6PWQBZTumzGrh6Hd9VCen+Yc=; b=XFq9sHRHLrYsqTjTmKJTXT1Ay4 wM2n8486mH5xIp9N1C3dPDLd6y0J5g0MyzEDJ3thYDlTHgj2dOpDOLyhyWraqT/WVMoOWcTJZs8oN s3tagxnk67VY7c/C624/GRK3blbOoVtY7Uiwaovlca+j6eEKp0U+v2Vxo4Lyx0ybrBkRBw7TPeveS ZKff0HB+afvq/IQpKJi+FZ9GnroHSqYcU2+GCafd5NenSTeunxd8JF/2cE7MUk1p71XutfK2pDdZ7 jtBfX8iuNpUPfqt/WurTtq4tVqLFnId68/1lFr3zWluDqeCs3T8mtg9Bx+kU2h6qCg+9Q/VT6wlFb LV7zA8xg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJwni-00000001hho-2nT9; Wed, 19 Jun 2024 15:00:42 +0000 Received: from mail-qv1-xf34.google.com ([2607:f8b0:4864:20::f34]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJwnd-00000001hfZ-2TtN for linux-arm-kernel@lists.infradead.org; Wed, 19 Jun 2024 15:00:39 +0000 Received: by mail-qv1-xf34.google.com with SMTP id 6a1803df08f44-6b072522bd5so31398506d6.2 for ; Wed, 19 Jun 2024 08:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718809232; x=1719414032; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=hSe7xh6KAt4sne8yLQr6PWQBZTumzGrh6Hd9VCen+Yc=; b=E+oAOk9tYxya2S46tp5cNYTc8A1ckHwPhmb5aRAI7xGIpP5IJqiU4R3w+IS0glD5kC q633+VVGIfaUo33CvleiagS6RmNBGWGY1rYoIMlKN1HThn9LYvXEc5BFt3Z36/ldJ+x5 kO3uhxd0dWmZIFTr9XXevFt5ckhGm/Op8LRVVfujnBYvQlv4AHqFlj44YGGOra6meNeM PXF5EYfaQSWwZ3sSZsagzW80t1fq0AAmvakMzaa4EAPyCVlE4PsrQQpRHEGIsBn5EoV/ p0cDBnS3ySMw9Rom1EFDib+eZr/grth1oExezxRaLrRSu+vCTwW/1KEQRXwfIZUJB4B1 wg9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718809232; x=1719414032; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hSe7xh6KAt4sne8yLQr6PWQBZTumzGrh6Hd9VCen+Yc=; b=N9bzXDjpCABscI1UQsbF7qh0Kq7GtTE7gwGg7mm8IweU+mCo0aQ2WDM9ZqnSmzZ4kg aE1qlGKhhyW8HF8gRBDojfsCSB7WjZZ6Jcw3sB2ECkCEP0FNPq5yrn9hgCnqRdyIEnbV jHH0KCJf9B4EAWLedWAcaP6l/X8k2g0LHZo4P0Q3S6UIrH6L1nhpMjOgHe1PYuxXrE6y Nx/9U+FzpQ+c7Z+dZfEudGWt1uDIeo9qtilQD+0fYHGsvqaC6Be96OvTBxlJTQrPbbVH WokSoxKIeobM4Ti4ksdmmXTwKmhFUIbVhmKL67tOkIIFvZLeLlln1ozT6B7VRjHV2CZR J2vg== X-Forwarded-Encrypted: i=1; AJvYcCV6/oUrYHG+DYQF2RMMrI1yqN5ghVRJAritrwYuxsfxi3WN8a4GZrnOvihPRtHeMT2dq19ugZaD9ntXviDGb6V8ElOyPVbKLrochki08X/9mkyCqsg= X-Gm-Message-State: AOJu0Yw1fXA69CWKOKRf/5umwZgcUoXw4PRzqjKRjEhFrXQUxQ3HOBhU yp3+9Jw5c3DkqfoOcJfFsKDROpCKoXdTPlP+AqX0emoFhuDfEoS9 X-Google-Smtp-Source: AGHT+IFMO2mnnq/pKqebuYpxsv8DFlI+YICYEc0pIpoy8PluBhBbtM2i6uRQLvJpntCKJejZy2TOjA== X-Received: by 2002:ad4:4433:0:b0:6b4:d299:e060 with SMTP id 6a1803df08f44-6b501eda83cmr26413976d6.64.1718809231655; Wed, 19 Jun 2024 08:00:31 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b4f7e0d927sm17249616d6.37.2024.06.19.08.00.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jun 2024 08:00:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfauth.nyi.internal (Postfix) with ESMTP id 031DA120006A; Wed, 19 Jun 2024 11:00:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 19 Jun 2024 11:00:30 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeeftddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpefhtedvgfdtueekvdekieetieetjeeihedvteehuddujedvkedtkeefgedv vdehtdenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhh phgvrhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunh drfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Jun 2024 11:00:28 -0400 (EDT) Date: Wed, 19 Jun 2024 08:00:27 -0700 From: Boqun Feng To: Benno Lossin Cc: Miguel Ojeda , Gary Guo , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, llvm@lists.linux.dev, Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Andreas Hindborg , Alice Ryhl , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Nathan Chancellor , Nick Desaulniers , kent.overstreet@gmail.com, Greg Kroah-Hartman , elver@google.com, Mark Rutland , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Catalin Marinas , torvalds@linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, Trevor Gross , dakr@redhat.com Subject: Re: [RFC 2/2] rust: sync: Add atomic support Message-ID: References: <20240612223025.1158537-3-boqun.feng@gmail.com> <0653b5d5-7a62-4baa-a500-4c110d816ba0@proton.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240619_080037_672681_88E3F8EE X-CRM114-Status: GOOD ( 53.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 19, 2024 at 09:09:46AM +0000, Benno Lossin wrote: [...] > >>> Then I might mis-understand Gary? He said: > >>> > >>> "Can we avoid two types and use a generic `Atomic` and then implement > >>> on `Atomic` and `Atomic` instead?" > >>> > >>> , which means just replace `impl AtomicI32` with `impl Atomic` to > >>> me. > >> > >> This is a fair interpretation, but what prevents you from merging the > >> impls of functions that can be? I assumed that you would do that > >> automatically. > >> > > > > I think you missed the point, Gary's suggestion at that time sounds > > like: let's impl Atomic and Atomic first, and leave rest of > > the work for later, that is a "do the design later" to me. > > Hmm, but wouldn't that just be less work for you? > Not really ;-) Committing to a generic interface without a vision/design is going to be a maintenace nightmare. I will need to deal the soundness issues and different ideas about what can be put in <..>. So I'd suggest we take great caution before we make our decision, and I may even ask for a formal proof of the soundness of a generic interface for key components such as atomics. Because last time I check, safety is what Rust brings on the table, right? Someone may say that non generic atomics is one of the biggest mistakes that Rust ever made. But I disagree. In fact when I saw this, my first impression was "these guys know their stuff": there are only a few types and operations that make sense, so putting them in a generic interface would be over-engineer (at least at the beginning). It's better correct than convenient/popular/aesthetical. So would you and Gary be interested at working on such a design and proof? Maybe someone else Cced would also be interested. Eventually we will need the tool of soundness proof for other types as well, that's going to be very vaulable. And having that would be the real "less work for me" ;-) Right now, I still plan to do in the current way (i.e. non-generic atomcis for i32, i64, isize) because there are already users [1], the correctness is easy to confirm and we won't confuse users with half-baked generic design. But should we have a sound Atomic design, I'm happy to adopt it ;-) [...] > >> Also to be aligned on the vision, I think we should rather talk about > >> the vision and not the design, since the design that we want to have now > >> can be different from the vision. On that note, what do you envision the > >> future of the atomic API? > >> > > > > Mine is simple, just providing AtomicI32 and AtomicI64 first, since > > there are immediate users right now, and should we learn more needs from > > the users, we get more idea about what a good API is, and we evolve from > > there. > > That is fine, but since we want to get generics in the future anyways, I > think it would be good to already implement them now to also gather > feedback on them. > [...] > > > > You mean you said it's a non-issue but gave me two counteract? If it's > > really a non-issue, you won't need a couneraction, right? In other words > > non-generic atomics do provide some value. > > The second counteractions would provide exactly the same API surface as > your non-generic version, so I don't see how going non-generic provides > any value over going generic. > The first approach was intended for a future in which we are not scared > of people using generic atomics in their structs. I don't know if we are > going to be in that future, so I think we should go with the second > approach for the time being. > Not going to reply the above right now, because I'm leaning more torwards switching when we have a sound Atomic design, but I want you to know I appreciate your input and explanation. > >> argument? Because I don't see anything else. > >> > >>>> - I don't think that we should resort to a script to generate the Rust > >>>> code since it prevents adding good documentation & examples to the > >>>> various methods. AFAIU you want to generate the functions from > >>>> `scripts/atomic/atomics.tbl` to keep it in sync with the C side. I > >>>> looked at the git log of that file and it hasn't been changed > >>>> significantly since its inception. I don't think that there is any > >>>> benefit to generating the functions from that file. > >>> > >>> I'll leave this to other atomic maintainers. > >>> > >>>> - most of the documented functions say "See `c_function`", I don't like > >>>> this, can we either copy the C documentation (I imagine it not > >>>> changing that often, or is that assumption wrong?) or write our own? > >>> > >>> You're not wrong. AN in C side, we do have some documentation template > >>> to generate the comments (see scripts/atomic/kerneldoc). But first the > >>> format is for doxygen(I guess?), and second as you just bring up, the > >>> templates are tied with the bash script. > >> > >> I see a bash script similarly to how Wedson sees proc macros ;) > >> We should try *hard* to avoid them and only use them when there is no > >> other way. > >> > > > > I will just start with the existing mechanism and try to evolve, whether > > it's a script or proc macro, I don't mind, I want to get the work done > > and most relevant people can understand in the way the they prefer and > > step-by-step, move it to the place I think is the best for the project. > > I don't think that we need a script or a proc macro. A few declarative > macros probably suffice if we go the way of generics. > Ah right. And even without generics we could use some declarative macros, and I'm happy to take a look at this and provide the alternative approach so we can choose a better one. [1]: https://lore.kernel.org/rust-for-linux/20240611114551.228679-2-nmi@metaspace.dk/ Regards, Boqun