All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Joel Fernandes" <joelagnelf@nvidia.com>,
	"Benno Lossin" <lossin@kernel.org>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] rust: io: use const generics for read/write offsets
Date: Mon, 22 Sep 2025 15:25:00 +0900	[thread overview]
Message-ID: <DCZ44OA67SLZ.HKORUXU2L9K2@nvidia.com> (raw)
In-Reply-To: <20250919205314.GA1884303@joelbox2>

On Sat Sep 20, 2025 at 5:53 AM JST, Joel Fernandes wrote:
> On Fri, Sep 19, 2025 at 11:26:19AM +0200, Benno Lossin wrote:
>> On Fri Sep 19, 2025 at 9:59 AM CEST, Joel Fernandes wrote:
>> > Hello, Danilo,
>> >
>> >> On Sep 19, 2025, at 1:26 AM, Danilo Krummrich <dakr@kernel.org> wrote:
>> >> 
>> >> On Thu Sep 18, 2025 at 8:13 PM CEST, Joel Fernandes wrote:
>> >>>> On Thu, Sep 18, 2025 at 03:02:11PM +0000, Alice Ryhl wrote:
>> >>>> Using build_assert! to assert that offsets are in bounds is really
>> >>>> fragile and likely to result in spurious and hard-to-debug build
>> >>>> failures. Therefore, build_assert! should be avoided for this case.
>> >>>> Thus, update the code to perform the check in const evaluation
>> >>>> instead.
>> >>> 
>> >>> I really don't think this patch is a good idea (and nobody I spoke to
>> >>> thinks so). Not only does it mess up the user's caller syntax
>> >>> completely, it is also
>> >> 
>> >> I appreacite you raising the concern,
>> >> but I rather have other people speak up
>> >> themselves.
>> >
>> > I did not mean to speak for others, sorry it came across like that
>> > (and that is certainly not what I normally do). But I discussed the
>> > patch in person since we are at a conference and discussing it in
>> > person, and I did not get a lot of consensus on this. That is what I
>> > was trying to say. If it was a brilliant or great idea, I would have
>> > hoped for at least one person to tell me that this is exactly how we
>> > should do it.
>> 
>> I'm also not really thrilled to see lots more turbofish syntax. However,
>> if we can avoid the nasty build_assert errors then in my opinion it's
>> better. (yes we do have Gary's cool klint tool to handle them correctly,
>
> Yes, thanks. Also I tried to apply this patch and it doesn't always work
> because of array indexing usecase in nova, where we compute the offset based
> on a runtime register index  (**/nova-core/**/macros.rs). Here idx is not a
> constant:
>
>             /// Read the array register at index `idx` from its address in `io`.
>             #[inline(always)]
>             pub(crate) fn read<const SIZE: usize, T>(
>                 io: &T,
>                 idx: usize,
>             ) -> Self where
>                 T: ::core::ops::Deref<Target = ::kernel::io::Io<SIZE>>,
>
> In **/ga102.rs, we have the following usage where ucode_idx cannot be const:
>
> regs::NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION::read(bar, ucode_idx).data()
>
> So I am afraid this wont work. Also even if it did work, it means now we have
> to also put idx as a const generic (turbofish syntax).

We could always use the `try_read*` variant for these, but that would
introduce runtime checking for errors that can't happen. We have been
pretty successful in avoiding using `try_read*` in Nova so far, and I
think that's something we should try to preserve as it brings confidence
that our register accesses are correct.

  reply	other threads:[~2025-09-22  6:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18 15:02 [PATCH] rust: io: use const generics for read/write offsets Alice Ryhl
2025-09-18 18:13 ` Joel Fernandes
2025-09-18 23:26   ` Danilo Krummrich
2025-09-19  7:59     ` Joel Fernandes
2025-09-19  9:26       ` Benno Lossin
2025-09-19 20:53         ` Joel Fernandes
2025-09-22  6:25           ` Alexandre Courbot [this message]
2025-09-19 20:56     ` Gary Guo
2025-09-19 23:56       ` Danilo Krummrich

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=DCZ44OA67SLZ.HKORUXU2L9K2@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=joelagnelf@nvidia.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.