Message-ID: <CANiq72kWGUbpDW+WjKki4JUYX63j_GFBcyQse-rgddwyoFw7cg@mail.gmail.com>
Date: Sat, 28 Jun 2025 16:29:31 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <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>, 
	Danilo Krummrich <dakr@...nel.org>, Daniel Stone <daniels@...labora.com>, Rob Herring <robh@...nel.org>, 
	Alice Ryhl <alice.ryhl@...gle.com>, Beata Michalska <beata.michalska@....com>, 
	Carsten Haitzler <carsten.haitzler@...s.arm.com>, 
	Boris Brezillon <boris.brezillon@...labora.com>, Ashley Smith <ashley.smith@...labora.com>, 
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	rust-for-linux@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH] Introduce Tyr

On Sat, Jun 28, 2025 at 3:06 PM Daniel Almeida
<daniel.almeida@...labora.com> wrote:
>
> The branch I shared is drm-misc-next plus a few dependencies, i.e.: 10 commits
> total if I counted it correctly - all of which have been sent to the list
> already and most of which have seen a quite a few iterations. I should have
> explicitly said this, though.

Ah, that helps, thanks. It is completely fine -- I am just pointing it
out in case it helps you make this easier to land and for others to
follow.

> Anyway, I thought that having a branch would be more tidy than listing them, as
> the branch shows in what order they're applied and etc. For example, the patch
> for read_poll_timeout was cherry-picked from Fujita's v12 series, and that was
> subsequently dropped in v13 until the rest of the series was merged on v15. I
> thought that referring to v12 of that series would be slightly confusing.

Yeah, the branch is definitely nice to have to see the end state you
want, but having the Lore links helps a lot clarifying what the
dependencies (and their version etc.) are. You can use that chance to
mention anything out of the ordinary for each dependency (e.g. like
you mentioned here).

> Yeah, it's a constant battle between having spelling check enabled (which on my
> case flags the code itself, thereby producing a mountain of false positives) vs
> not. In this case, the bad spelling won :)

I would suggest using `checkpatch.pl` with `--codespell` (I don't know
if it catches this one -- I just saw it in my client -- but their
dictionary definitely did catch some for us in the past).

> Hmm, I must say I did not know that this was a thing.
>
> Why is it better than [#allow] during the development phase?

I have some notes at:

    https://docs.kernel.org/rust/coding-guidelines.html#lints

Generally speaking, we default to `expect` unless there is a reason
not to (I list some possible reasons in the link), because `expect`
forces us to clean it when unneeded.

Not sure what you mean by "development phase" -- even if Tyr is under
development, it should still try to conform to the usual guidelines.
Of course, if a particular `expect` would be a pain, then please feel
free to use `allow`. But is that case here? i.e. you will want to
remove the `allow` anyway when you add the new code, no?

Thanks!

Cheers,
Miguel

Powered by blists - more mailing lists