From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 600911E9B0D; Fri, 21 Feb 2025 12:31:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740141104; cv=none; b=UBlZ43rYBBdILq5rz46UDfXZQM35TAcm4mVrIFlozuQLxVw2ilJ7M3oubYDyWPAoZM3q7Lu0oR/kCvr7wnWVJ6Qz5j9iSghIsyfxepIU+553X5mjpgT0zRODlseZXhxHJlQLJqmUEoix+BFhhJO5LR5WC5Y8UKJlDHNYmoznP94= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740141104; c=relaxed/simple; bh=q8WccUvMCEjEq8D445PcgFQTfSEcnZeGJELN1WQnJpM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bSSxQgY1k6/2U46xavAXowEdzda0liY9GCoIcgmRnloi6fFu//MgDtShHJJYLcZROQiCULWFPZqh0eZLwriUSUGkU04w5tyC5SSfLURYqTp28yn+fuEPtzOpVnC+m3OLDbQX8RxcyUHl7JTGH5j86lSGnfFbuya0NPoU7JwQWVI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TyleH0/G; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TyleH0/G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6271BC4CED6; Fri, 21 Feb 2025 12:31:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740141103; bh=q8WccUvMCEjEq8D445PcgFQTfSEcnZeGJELN1WQnJpM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TyleH0/GM5J84z9onnQrMroU9wvXKOptL1fakQv4PcmqK7ukY1tfLzxO0Y2HrOREJ LmwH48qpkhDBzGHgcKREumi0uVK39mfYYiUTbfeqhX7+FiI9Hdi9rcaUldEeITPuDt GzH0OIGc3OQxBQTzYc7yhI6cIHL5XfseEm2jn9ihiyup/43v5DeMtg3+5t3kMVUv5X msW72GqQ4gywSELxcAx6InTB5uoHXAPsolLgGSmp+tyYATQ7gWAe1MnEcOvlwRZyA1 +ai0Pu0D9sf6ZLcKZQgXGD64UT2LIeHdX993FSvAzxpRAe4IBwarUfBw1fUvlxd6VZ bBZztWPKcn0fw== Date: Fri, 21 Feb 2025 13:31:38 +0100 From: Danilo Krummrich To: Alexandre Courbot Cc: John Hubbard , Daniel Almeida , Dave Airlie , Timur Tabi , "dri-devel@lists.freedesktop.org" , "rust-for-linux@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "nouveau@lists.freedesktop.org" , Ben Skeggs , Nouveau Subject: Re: [PATCH RFC 1/3] rust: add useful ops for u64 Message-ID: References: <1b8921d46f7d70c7467ea0940d60220f05cccc5d.camel@nvidia.com> <1597EDB7-D91B-4660-ADDC-D2252B26CB22@collabora.com> <41cf1c79-f61c-47e7-a0ed-afb8e82d50e6@nvidia.com> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Feb 21, 2025 at 08:35:54PM +0900, Alexandre Courbot wrote: > On Thu Feb 20, 2025 at 9:14 AM JST, John Hubbard wrote: > > On 2/19/25 3:13 PM, Daniel Almeida wrote: > >>> On 19 Feb 2025, at 17:23, Dave Airlie wrote: > >>> On Thu, 20 Feb 2025 at 06:22, John Hubbard wrote: > >>>> On 2/19/25 4:51 AM, Alexandre Courbot wrote: > >>>>> Yes, that looks like the optimal way to do this actually. It also > >>>>> doesn't introduce any overhead as the destructuring was doing both > >>>>> high_half() and low_half() in sequence, so in some cases it might > >>>>> even be more efficient. > >>>>> > >>>>> I'd just like to find a better naming. high() and low() might be enough? > >>>>> Or are there other suggestions? > >>>>> > >>>> > >>>> Maybe use "32" instead of "half": > >>>> > >>>> .high_32() / .low_32() > >>>> .upper_32() / .lower_32() > >>>> > >>> > >>> The C code currently does upper_32_bits and lower_32_bits, do we want > >>> to align or diverge here? > > > > This sounds like a trick question, so I'm going to go with..."align". haha :) > > > >>> > >>> Dave. > >> > >> > >> My humble suggestion here is to use the same nomenclature. `upper_32_bits` and > >> `lower_32_bits` immediately and succinctly informs the reader of what is going on. > >> > > > > Yes. I missed the pre-existing naming in C, but since we have it and it's > > well-named as well, definitely this is the way to go. > > Agreed, I wasn't aware of the C equivalents either, but since they exist > we should definitely use the same naming scheme. IIUC, we're still talking about extending the u64 primitive type. Hence, I think there is no necessity to do align with the corresponding C nameing scheme. I think this would only be the case if we'd write an abstraction for the C API. In this case though we extend an existing Rust type, so we should do something that aligns with the corresponding Rust type. In this specific case I think it goes hand in hand though. - Danilo