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

John Hubbard
2025-12-01T23:15:20Z

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