linux-kernel - Re: [PATCH v3] rust: clist: Add support to interface with C linked lists

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <733283c8-03d8-438f-8c80-5a51714504b1@nvidia.com>
Date: Mon, 1 Dec 2025 15:15:07 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Joel Fernandes <joelagnelf@...dia.com>, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 nouveau@...ts.freedesktop.org, Danilo Krummrich <dakr@...nel.org>,
 Dave Airlie <airlied@...il.com>
Cc: Alexandre Courbot <acourbot@...dia.com>,
 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,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
 Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Timur Tabi <ttabi@...dia.com>, Joel Fernandes <joel@...lfernandes.org>,
 Lyude Paul <elle@...thered-steel.dev>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Andrea Righi <arighi@...dia.com>, Philipp Stanner <phasta@...nel.org>
Subject: Re: [PATCH v3] rust: clist: Add support to interface with C linked
 lists

On 12/1/25 3:09 PM, Joel Fernandes wrote:
> On 12/1/2025 5:52 PM, John Hubbard wrote:
>>>> And actually, after writing the above...I still think it would be better
>>>> to post this with its first caller (DRM_BUDDY, or BUDDY_DRM_ALUMNI, or
>>>> however it ends up), so that we can see how it looks and behaves in
>>>> practice.
>>>>
>>>> What's the rush?
>>> Who said anything about a rush? I am really confused by what you mean. It is
>>> useful to post patches even if there are external dependencies to get feedback.
>>> So this is also an invalid review comment unfortunately. There is no rush, this
>>> is v3 now, did you miss that?
>>>
>> I mean, doctests are far weaker than actual code that uses the new API.
>> It feels rushed to propose merging code without a caller. And I don't
>> think doctests are a "real enough" caller.
> 
> Actually I was already rebasing my DRM buddy bindings patches today. So the next
> version was already going to be with the actual DRM buddy bindings (inclusive of
> the clist patches), now that clist has mostly settled. The point of posting the
> clist series was to focus on just that part and get it right. If you notice, my
> first version included the DRM buddy user as well but clist required a lot of
> changes first.

Excellent!

> 
> I don't think one needs to include all users in a series if the series is
> sufficiently complex (as long as you posted the user or share a tree using it -
> which I already did in the v1). Then the maintainers can decide if it needs to
> be pulled in advance or with the user. That's really up to a maintainer. I
> certainly want clist to merged only once the drm buddy bindings go with it - why

Probably good to say that directly, in a cover letter.

> else would we want to do that? There is absolutely no reason. I am unable to
> find where you go the idea that I was proposing merging clist without the drm
> buddy bindings - there is little reason to do that considering clist.rs is
> mostly independent of other things and is really easy to rebase.
>

Just the fact that these are non-RFC patches.

thanks,
John Hubbard