[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4324469D-4C47-441E-9AD3-54CEE379537C@nvidia.com>
Date: Sat, 4 Oct 2025 16:14:17 +0000
From: Joel Fernandes <joelagnelf@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"dakr@...nel.org" <dakr@...nel.org>, Alistair Popple <apopple@...dia.com>,
Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Boqun
Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
"bjorn3_gh@...tonmail.com" <bjorn3_gh@...tonmail.com>, Benno Lossin
<lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl
<aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, David Airlie
<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, John Hubbard <jhubbard@...dia.com>,
Timur Tabi <ttabi@...dia.com>, "joel@...lfernandes.org"
<joel@...lfernandes.org>, Elle Rhumsaa <elle@...thered-steel.dev>, Yury Norov
<yury.norov@...il.com>, Daniel Almeida <daniel.almeida@...labora.com>, Andrea
Righi <arighi@...dia.com>, "nouveau@...ts.freedesktop.org"
<nouveau@...ts.freedesktop.org>, Alexandre Courbot <acourbot@...dia.com>
Subject: Re: [PATCH v5 6/9] rust: bitfield: Add KUNIT tests for bitfield
> On Oct 3, 2025, at 8:38 PM, Alexandre Courbot <acourbot@...dia.com> wrote:
>
> On Sat Oct 4, 2025 at 12:23 AM JST, Joel Fernandes wrote:
>>> - The right field is actually written (i.e. if the offset is off by one,
>>> the getter will return the expected result even though the bitfield
>>> has the wrong value),
>>> - No other field has been affected.
>>>
>>> So something like:
>>>
>>> pte = pte.set_present(true);
>>> assert!(pte.present());
>>> assert(pte.into(), 0x1u64);
>>>
>>> pte = pte.set_writable(true);
>>> assert!(pte.writable());
>>> assert(pte.into(), 0x3u64);
>>>
>>> It might look a bit gross, but it is ok since these are not doctests
>>> that users are going to take as a reference, so we case improve test
>>> coverage at the detriment of readability.
>>>
>>
>> Ack. I will add these.
>>
>> Thanks for the review! (I am assuming with these changes you're Ok with me
>> carrying your Reviewed-by tag on this patch as well, but please let me know if
>> there is a concern.)
>
> Please do not add tags that haven't been explicitly given. If we start
> assuming one another's stance about patches, the trust we can have in
> these tags is significantly reduced.
Oh, I thought you told me you reviewed the patch privately, but consider the tag dropped.
>
> Doing so also doesn't achieve anything in terms of efficiency; if I am
> ok with v3 I can give my Reviewed-by on it, and the tag can be picked up
> along with the patch when it is applied.
Well, it can be efficient. It really depends. I have been contributing upstream for about 15 years if you see the git log, often when someone chats privately with me like you did and they told me they are ok with a patch, I save them the trouble and add their review tag especially after they already added their tag to all my other patches. Surprisingly though this is probably the first time anyone has been pissed off about it. Anyway I will not add your tag henceforth unless you publicly reply (or you let me know otherwise by chat).
Anyway thank you for the review of this patch,
Joel
Powered by blists - more mailing lists