From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C144130487; Thu, 13 Jun 2024 19:05:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718305553; cv=none; b=BWwqOT80akdOGLEzL3GUPxmwrA4K9/gJ8LdnfCZO8Oy3ZGsRjf/RUgHoveVqz5nGXn9IldOUuF2FgO0zESqI3JRIZx8jREpJDjderGiSYVo9dYPCHV9Yvj+TOa4EenguEfxPnHI1Mv5tuVCzXVyQ4hhqZ/qoNazJUN2gW1LNt5I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718305553; c=relaxed/simple; bh=Gjcaa8+6uCgQkQx/KQDUdcFBpRQxKJkZkyyvTptG/DQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mjR4T4hwWQYQ5eNWRWXV8mNfRGP8EdGkP+K4GP1hwbgCiQ/e04F654vLg5RsNacRxu/mDD2qyop3xi7Lx2BLAlKO+bhvmcZv3Kf7I5F/czVaAu8y18lOyG0P6HeUt8Ef+/rJsngxBAzGXwum743bjG9/6p+HBwldlh4rkCVtomM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PCUvASAU; arc=none smtp.client-ip=209.85.160.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PCUvASAU" Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-44055ca3103so7775101cf.3; 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=vger.kernel.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=PCUvASAUnkWfnh4k6w1wQPRfaMgJclN0P+i9l1fhmBAU1LQGuEJ5B28lINOklT7vM+ 9nFPMRNg8G4uWSAYlMg3oIbOQpdAk7kYrqjnBiM+Xoub8yNgBnyF07ZmUHUsOYl9VsgM Zt86rgo1hIkye9kpw2CQDzC3L0OTNVrESueWpsNZuQQNxDxfxK7X/Od7H4jUpxH4BTtr 5V93w03AZDkcsi7TOjz17vaAse6mCz7TlWlVOcraaUxWBK/PVhRYxkN/NfJkhbhrYBnf 4PCxYSto5wua9AkAtIUeGgt1l3shzhtLAOwr8jRpDz/sJDt6jRTjp4tN/RVoU50RCKz8 jmfA== 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=bs5Ve05CCHlwNIfEkUWnKnG2nUqB9zSoJw/z31wmlBpKu3HwaxOw7X0QvbRmsQpZS5 R92rZjO2CPGulTrmxujgJAT1cP7QO/1Lftgc7A2YaZUHHUz+X+bP64alqPuRJBPtdpQb miBzgVN2o5DkAKlJ3NlNOl/1JQcsWIpDXJeqYe08oUsiy2q/yplYdV2Xjtw9y0lk2Qzs sYJoaIpLuMcaMdgpSFaSSNPjRFR1etjLiowmPhiLLQSf4xHmx5noqmwIDhUJi4lR8Lb2 C5enHtweNgpkd7C+KpkgB+q6rWMuMxCHX8RsvFY5ogwOUuBeoJopCYFevJ7JZ2jmFm86 MVpw== X-Forwarded-Encrypted: i=1; AJvYcCX9jtuYy2jTgxx93CulyRdakYcO/brK9SlsVWFm6fbm09hhbx1WHnEqSksROd/cK3qL44+2NvfXo0viEwU+anWsbM/NwtnCGKnBL8DiRBD3RAinUZurXbTwOqrE5nIV48yWEkuXpFfPSyBt6Ht5/VScKTmghbQlb1RpU5cSHdBUZQRCy6KVJbKhkROwK48LfukykwCVuUvI8cYDWUdHhmFcOWwCcMOP3A== X-Gm-Message-State: AOJu0YzmFcVbp7F0UlSLf62Xs+wKw/RZtT2OZETE1BBievjkQLMo5tAc IPTbJ5obNz4YVNOuAapcFkop2GI4EwEOHnZpuApI6hlKpTyxhVmn 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> Precedence: bulk X-Mailing-List: linux-arch@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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