From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Joel Fernandes" <joelagnelf@nvidia.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Jonathan Corbet" <corbet@lwn.net>
Cc: "John Hubbard" <jhubbard@nvidia.com>,
"Ben Skeggs" <bskeggs@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
<linux-kernel@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
<nouveau@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 17/21] rust: num: Add an upward alignment helper for usize
Date: Sat, 03 May 2025 10:59:39 +0900 [thread overview]
Message-ID: <D9M5K55GTN6S.1X827WU0Z50UM@nvidia.com> (raw)
In-Reply-To: <d6962ea3-282d-437c-b3cf-ce701d514558@nvidia.com>
On Sat May 3, 2025 at 4:59 AM JST, Joel Fernandes wrote:
> Hello, Alex,
>
> On 5/2/2025 12:57 AM, Alexandre Courbot wrote:
>> On Thu May 1, 2025 at 9:58 PM JST, Alexandre Courbot wrote:
>>> From: Joel Fernandes <joelagnelf@nvidia.com>
>>>
>>> This will be used in the nova-core driver where we need to upward-align
>>> the image size to get to the next image in the VBIOS ROM.
>>>
>>> [acourbot@nvidia.com: handled conflicts due to removal of patch creating
>>> num.rs]
>>>
>>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>>> ---
>>> rust/kernel/lib.rs | 1 +
>>> rust/kernel/num.rs | 21 +++++++++++++++++++++
>>> 2 files changed, 22 insertions(+)
>>>
>>> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
>>> index ab0286857061d2de1be0279cbd2cd3490e5a48c3..be75b196aa7a29cf3eed7c902ed8fb98689bbb50 100644
>>> --- a/rust/kernel/lib.rs
>>> +++ b/rust/kernel/lib.rs
>>> @@ -67,6 +67,7 @@
>>> pub mod miscdevice;
>>> #[cfg(CONFIG_NET)]
>>> pub mod net;
>>> +pub mod num;
>>> pub mod of;
>>> pub mod page;
>>> #[cfg(CONFIG_PCI)]
>>> diff --git a/rust/kernel/num.rs b/rust/kernel/num.rs
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..953c6ab012601efb3c9387b4b299e22233670c4b
>>> --- /dev/null
>>> +++ b/rust/kernel/num.rs
>>> @@ -0,0 +1,21 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +//! Numerical and binary utilities for primitive types.
>>> +
>>> +/// A trait providing alignment operations for `usize`.
>>> +pub trait UsizeAlign {
>>> + /// Aligns `self` upwards to the nearest multiple of `align`.
>>> + fn align_up(self, align: usize) -> usize;
>>> +}
>>
>> As it turns out I will also need the same functionality for u64 in a
>> future patch. :) Could we turn this into a more generic trait? E.g:
>>
>> /// A trait providing alignment operations for `usize`.
>> pub trait Align {
>> /// Aligns `self` upwards to the nearest multiple of `align`.
>> fn align_up(self, align: Self) -> Self;
>> }
>>
>> That way it can be implemented for all basic types. I'd suggest having a local
>> macro that takes an arbitrary number of arguments and generates the impl blocks
>> for each of them, which would be invoked as:
>>
>> impl_align!(i8, u8, i16, u16, ...);
>
> I actually tried this initially before settling for the simpler solution.
>
> We can do this in 3 ways I think, generics, macros or both.
>
> Unlike the last attempt, this time I did get generics to work. So how about this?
>
> use core::ops::{Add, Sub, BitAnd, Not};
>
> pub trait AlignUp {
> fn align_up(self, alignment: Self) -> Self;
> }
>
> impl<T> AlignUp for T
> where
> T: Copy
> + Add<Output = T>
> + Sub<Output = T>
> + BitAnd<Output = T>
> + Not<Output = T>
> + From<u8>,
> {
> fn align_up(self, alignment: Self) -> Self {
> let one = T::from(1u8);
> (self + alignment - one) & !(alignment - one)
> }
> }
>
> I know you must be screaming the word monomorphization, but it is clean code and
> I'm willing to see just how much code the compiler generates and does not
> requiring specifying any specific types at all!
No, I think this is great - monomorphization only happens as the code is
used, so it won't be a problem. And the compiler should just inline that
anyway (let's add an `#[inline]` to be sure although I'm not convinced
it is entirely necessary).
>
> This also could be simpler if we had num_traits in r4L like userspace, because
> num_trait's PrimInt encapsulates all the needed ops.
>
> use num_traits::PrimInt;
>
> pub trait RoundUp {
> fn round_up(self, alignment: Self) -> Self;
> }
>
> impl<T> RoundUp for T
> where
> T: PrimInt,
> {
> fn round_up(self, alignment: Self) -> Self {
> (self + alignment - T::one()) & !(alignment - T::one())
> }
> }
>
> fn main() {
> let x: u32 = 1234;
> let y: usize = 1234;
>
> // Output 1536
> println!("u32: {}", x.round_up(512));
> println!("usize: {}", y.round_up(512));
> }
>
> For the monomorphization issues, I do wish Rust in general supported restricting
> types further so if we could say "where T is u32, usize etc." but it does not
> afaics, so maybe we can do this then?
>
> /// This bit can go into separate module if we want to call it
> /// 'num_traits' something.
>
> ppub trait Alignable:
> Copy
> + Add<Output = Self>
> + Sub<Output = Self>
> + BitAnd<Output = Self>
> + Not<Output = Self>
> + From<u8>
> {
> }
>
> impl Alignable for usize {}
> impl Alignable for u8 {}
> impl Alignable for u16 {}
> impl Alignable for u32 {}
> impl Alignable for u64 {}
> impl Alignable for u128 {}
>
> //////////////////////
>
> And then num.rs remains simple but restricted to those types:
>
> pub trait AlignUp {
> fn align_up(self, alignment: Self) -> Self;
> }
>
> impl<T> AlignUp for T
> where
> T: Alignable ,
> {
> fn align_up(self, alignment: Self) -> Self {
> let one = T::from(1u8);
> (self + alignment - one) & !(alignment - one)
> }
> }
>
> If we dislike that, we could go with the pure macro implementation as well. But
> I do like the 'num_traits' approach better, since it keeps the align_up
> implementation quite clean.
This looks very rust-y and I like it. I guess Alignable (maybe with a
more generic name because I suspect these properties can be used for
other things than aligning as well) could be in the `num` module without
any problem.
>
> pub trait AlignUp {
> fn align_up(self, alignment: Self) -> Self;
> }
>
> macro_rules! align_up_impl {
> ($($t:ty),+) => {
> $(
> impl AlignUp for $t {
> fn align_up(self, alignment: Self) -> Self {
> (self + alignment - 1) & !(alignment - 1)
> }
> }
> )+
> }
> }
>
> align_up_impl!(usize, u8, u16, u32, u64, u128);
>
> Or, we can even combine the 2 approaches. Use macros for the "impl Alignable"
> and use generics on the Alignable trait.
>
> macro_rules! impl_alignable {
> ($($t:ty),+) => {
> $(
> impl Alignable for $t {}
> )+
> };
> }
>
> impl_alignable!(usize, u8, u16, u32, u64, u128);
>
> pub trait AlignUp {
> fn align_up(self, alignment: Self) -> Self;
> }
>
> impl<T> AlignUp for T
> where
> T: Alignable,
> {
> fn align_up(self, alignment: Self) -> Self {
> let one = T::from(1u8);
> (self + alignment - one) & !(alignment - one)
> }
> }
>
> Thoughts?
I think that's the correct way to do it and am fully on board with this
approach.
The only thing this doesn't solve is that it doesn't provide `const`
functions. But maybe for that purpose we can use a single macro that
nicely panics at build-time should an overflow occur.
Cheers,
Alex.
next prev parent reply other threads:[~2025-05-03 1:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 12:58 [PATCH v2 00/21] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 01/21] rust: devres: allow to borrow a reference to the resource's Device Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 02/21] rust: dma: expose the count and size of CoherentAllocation Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 03/21] gpu: nova-core: derive useful traits for Chipset Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 04/21] gpu: nova-core: add missing GA100 definition Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 05/21] gpu: nova-core: take bound device in Gpu::new Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 06/21] gpu: nova-core: define registers layout using helper macro Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 07/21] gpu: nova-core: fix layout of NV_PMC_BOOT_0 Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 08/21] gpu: nova-core: introduce helper macro for register access Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 09/21] gpu: nova-core: move Firmware to firmware module Alexandre Courbot
2025-05-02 21:14 ` Timur Tabi
2025-05-07 13:42 ` Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 10/21] rust: make ETIMEDOUT error available Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 11/21] gpu: nova-core: wait for GFW_BOOT completion Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 12/21] gpu: nova-core: add DMA object struct Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 13/21] gpu: nova-core: register sysmem flush page Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 14/21] gpu: nova-core: add helper function to wait on condition Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 15/21] gpu: nova-core: add falcon register definitions and base code Alexandre Courbot
2025-05-01 13:52 ` Joel Fernandes
2025-05-01 14:18 ` Alexandre Courbot
2025-05-01 14:41 ` Joel Fernandes
2025-05-01 12:58 ` [PATCH v2 16/21] gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTS Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 17/21] rust: num: Add an upward alignment helper for usize Alexandre Courbot
2025-05-01 15:19 ` Timur Tabi
2025-05-01 15:22 ` Joel Fernandes
2025-05-01 15:31 ` Timur Tabi
2025-05-01 15:31 ` Joel Fernandes
2025-05-01 21:02 ` Alexandre Courbot
2025-05-01 21:52 ` Joel Fernandes
2025-05-02 4:57 ` Alexandre Courbot
2025-05-02 19:59 ` Joel Fernandes
2025-05-03 1:59 ` Alexandre Courbot [this message]
2025-05-03 3:02 ` Joel Fernandes
2025-05-03 14:37 ` Alexandre Courbot
2025-05-05 15:25 ` Joel Fernandes
2025-05-07 14:11 ` Alexandre Courbot
2025-05-03 14:47 ` Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 18/21] nova-core: Add support for VBIOS ucode extraction for boot Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 19/21] gpu: nova-core: compute layout of the FRTS region Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 20/21] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS Alexandre Courbot
2025-05-01 12:58 ` [PATCH v2 21/21] gpu: nova-core: load and " Alexandre Courbot
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=D9M5K55GTN6S.1X827WU0Z50UM@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bskeggs@nvidia.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox