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 6D2C2C27C4F for ; Thu, 13 Jun 2024 19:06:10 +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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ffc3VX56CZ7smTmD9fwLf7azxKQfNJQFr7EZRiaut9M=; b=T9AnEMs67FYKYsww+FMzVE2h8Z f/TWSE18L96moe/hZ0BgayBFNrN67Kr+looAJL6uK1xemjOSm7a5owZXlAkSqT7bYYbgJzo3F6X7k x7PkJOG6I7mxR+UULGu2zQyr7ebGGePvQP1QSe5b7FA7f086I4qFR4BEaWVva1tCeDaBWhp9pUb8j 42UAiJy7FzWi6/AyY1O+lqV3ZwQBcn0wgfkNytniKwZSGxd2yd4h49VbXzMDotQfF5J8iA08BgY9l mAhakyrQY6lkpYXm4jHyD+qF6Sah4/EGFR4YpMK9LJTMPVH9CvW9bBz2xZo/15oy71ffxEWwwXaYj 834mkvSQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHplj-00000000Chs-1Akp; Thu, 13 Jun 2024 19:05:55 +0000 Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHplg-00000000Ch2-1E0B for linux-arm-kernel@lists.infradead.org; Thu, 13 Jun 2024 19:05:53 +0000 Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-4410316ecfeso7652231cf.1 for ; Thu, 13 Jun 2024 12:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718305551; x=1718910351; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:from:to:cc:subject:date:message-id:reply-to; bh=Ffc3VX56CZ7smTmD9fwLf7azxKQfNJQFr7EZRiaut9M=; b=Uh/8Wz8vtVKf1pqXKezZQvwJc+u02kDcqwOvAOkqR/wey9RO1TripFdHYZTLP+JUCV 3L3XKl5iia4l2+G6LdC7ZZMdN50TANvqBl6oZe+t3hjXfYwuRxxcBbyYPLYKOYgZNLKk 4+0tqOQ6XXqhQxjGLzxoDh1xeCNUv/LxDUGWh8CvPWHCgcphJmexdUfkg2AE9afNpA2s 2G6oKmD9n+iko4VOIyRM1F0qtVpWPKOZxUWLsPqRIRCyyH+18Jn/hxrP02HPU4NT6Itw bvBdjJAK3sa+mOVlW8crrVsmXqFW6XIMC/64LghL3PVz3NK/fywu4DNkMzLIMsGl4YdJ eQIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718305551; x=1718910351; h=in-reply-to:content-transfer-encoding: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=Ffc3VX56CZ7smTmD9fwLf7azxKQfNJQFr7EZRiaut9M=; b=X/I/8NCTQlrSsv0MoVl1pGwXQjFH1gXAPUOyoFXQSGuvOGzlO88ey24ANRJO6evg6s AXMA/xGWpilJ6QpkYF1znev1beQ5sIcFViTwAMr+fNXbp006jxTO3ei2JlkxNGc5Fm4j E6EMgZzBv7mblG/YggRSDG+RgXenpLF+uoD4tgbypK7fEFIgVgyXZvdaXTJZReoonIHJ bPdWns5r24eUFJ7vdKoOZsBdc4N0KOeIcGx6IHkOV8lSAtLpYOXvM7DN7xZgUow5U3yk xc2Bp3ibywABgK4G6sJjcE6XdW1dxqkiKB7RgIpirqsWoux6+HjS7MO1goPUhHiLq14c 6ycA== X-Forwarded-Encrypted: i=1; AJvYcCVUP38loAdCt1UBILeTQNoXdjml266FeaLzFH8+m2kOQZbC4/B7v8LPfZ/lfYoFFDK6NvifNxvzfAGZ4QJooX8icF55PVSZ+rVA9Id7PEkJODoWmZM= X-Gm-Message-State: AOJu0YzOoyH9N+F/1UhhdaURj2PjaQouYA6lLgLcEpaIXWUBdmFnKa9k CZGQnUwQYqwhD2pP3FmhRHo0t9zfGYGHwJkI19lcrDw7vHdPLRLt X-Google-Smtp-Source: AGHT+IE7frHfV9qWWrHFx6ZJCKnyiIFeH/wvgqxxR+AWnNkmcvkTjALGUbQSHHQF3wfhTv0YEkSdrg== X-Received: by 2002:a05:622a:284:b0:43a:f698:2b21 with SMTP id d75a77b69052e-442168efe33mr5802941cf.36.1718305550923; Thu, 13 Jun 2024 12:05:50 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-441f310c9f3sm8692321cf.94.2024.06.13.12.05.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jun 2024 12:05:50 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfauth.nyi.internal (Postfix) with ESMTP id D6B961200068; Thu, 13 Jun 2024 15:05:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 13 Jun 2024 15:05:48 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedujedgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtugfgjgesthekredttddtjeenucfhrhhomhepueho qhhunhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtf frrghtthgvrhhnpeevgffhueevkedutefgveduuedujeefledthffgheegkeekiefgudek hffggeelfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsohhquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeeh tdeigedqudejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmse hfihigmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Jun 2024 15:05:47 -0400 (EDT) Date: Thu, 13 Jun 2024 12:05:18 -0700 From: Boqun Feng To: Miguel Ojeda Cc: 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 , Benno Lossin , 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-1-boqun.feng@gmail.com> <20240612223025.1158537-3-boqun.feng@gmail.com> <20240613144432.77711a3a@eugeo> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240613_120552_449784_DF44B472 X-CRM114-Status: GOOD ( 23.53 ) 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 Thu, Jun 13, 2024 at 07:22:54PM +0200, Miguel Ojeda wrote: > On Thu, Jun 13, 2024 at 6:31 PM Boqun Feng wrote: > > > > So let's start with some basic and simple until we really have a need > > for generic `Atomic`. Thoughts? > > I don't want to delay this, but using generics would be more flexible, > right? e.g. it could allow us to have atomics of, say, newtypes, if > that were to be useful. > > Is there a particular disadvantage of using the generics? The two > cases you mentioned would just be written explicitly, right? > > One disadvantage would be that they are different from the Rust > standard library ones, e.g. in case we wanted third-party code to use > them, but could be provided if needed later on. > Well, the other thing is AtomicI32 -> atomic_t and AtomicI64 -> atomic64_t are perfect mappings, and we can treat AtomicI32 and AtomicI64 as a separate layer that wires C atomics into Rust. As I said, we can build `Atomic` on top of this layer, like: Atomic | V AtomicI{32,64} | V atomic{,64}_t and if we drop this layer, the dependencies become: Atomic <- Atomic | V atomic{,64}_t i.e. in the same layer of Atomic, some of them directly depend on some other Atomic types, which doesn't look very clean to me. And it might be difficult for architecture maintainers to track the exact dependency for Rust code. This is also the reason why I didn't use Rust macros to generate AtomicI32 and AtomicI64 implementation: I use a script to generate .rs file. This ensures AtomicI32 and AtomicI64 stay with the exact same set of APIs as atomic{,64}_t (described by scripts/atomic/atomics.tbl. Put it in another way, I guess you can think AtomicI32 and AtomicI64 as some sort of intrinsic layer provided by C. And should we need it, we can build an Atomic layer on top of it. Does this make sense? Regards, Boqun > Cheers, > Miguel