Nouveau - Dec 2025 - [PATCH v3] rust: clist: Add support to interface with C linked lists

On 12/1/2025 5:17 PM, John Hubbard wrote:
> On 12/1/25 12:32 PM, Joel Fernandes wrote:
>> On 11/30/2025 7:34 PM, John Hubbard wrote:
>>> On 11/29/25 1:30 PM, Joel Fernandes wrote:
> ...
>>> This is sufficiently tricky that I think it needs some code to
exercise it.
>>>
>>> Lately I'm not sure what to recommend, there are several
choices, each with
>>> trade-offs: kunit, samples/rust, or even new DRM Rust code. Maybe
the last
>>> one is especially nice, because it doesn't really have many
downsides.
>>>
>>> Rather than wait for any of that, I wrote a quick
samples/rust/rust_clist.rs
>>> and used it to sanity check my review findings, which are below.
>>
>> In v1, I had a samples/rust/ patch, but everyone's opinion almost
unanimously
>> was this does not belong in a sample, but rather in doctests. What in
the sample
>> is not supported by the current doctest? If something is missing, I
think I can
>> add it in. Plus yes, DRM_BUDDY is going to be a consumer shortly.
> 
> Well, I won't contest the choice of doctests, since wiser heads than
mine
> have already worked through the tradeoffs.
> 
> But for API developers, the problem with doctests is that no one has ever
> actually *run* the code. It's just a build test. And so critical bugs,
such
> as the kernel crash/hang below, are missed.
You may want to read [1]. CONFIG_RUST_KERNEL_DOCTESTS are run at runtime. You
enable it and boot the kernel. The documentation clearly says "doctests get
compiled as Rust kernel objects, allowing them to run against a built
kernel.".
And this is how I have run it as well.

[1] https://docs.kernel.org/rust/testing.html

This also explains why you think list_add_tail() is a noop in my patch, which it
is not.
> 
> I would humbly suggest that you build and *run* your own samples code, for
> new code that has no users yet.
Yes, I already have an internal tree running it. :) I am not sure why the
assume_init() triggered for you but not for me, I don't think has anything
to do
with doctests since the doctests is in fact just rust code compiled as KUNIT
tests.
> Because if you are skipping steps like this (posting the code before
> there is an actual caller), then the documentation of how to use it
> is not "just documentation" anymore--it really needs to run
correctly.
No, that's the thing, these are run. You really are in the wrong here and
appear
to not understand how doctests work.
> 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?

Thanks.

On 12/1/25 2:43 PM, Joel Fernandes wrote:
> On 12/1/2025 5:17 PM, John Hubbard wrote:
>> On 12/1/25 12:32 PM, Joel Fernandes wrote:
>>> On 11/30/2025 7:34 PM, John Hubbard wrote:
>>>> On 11/29/25 1:30 PM, Joel Fernandes wrote:
>> ...
> You may want to read [1]. CONFIG_RUST_KERNEL_DOCTESTS are run at runtime.
You
> enable it and boot the kernel. The documentation clearly says
"doctests get
> compiled as Rust kernel objects, allowing them to run against a built
kernel.".
> And this is how I have run it as well.
> 
> [1] https://docs.kernel.org/rust/testing.html
> 
> This also explains why you think list_add_tail() is a noop in my patch,
which it
> is not.
Yes, I forgot that they are actually run, you are right.
> 
>>
>> I would humbly suggest that you build and *run* your own samples code,
for
>> new code that has no users yet.
> 
> Yes, I already have an internal tree running it. :) I am not sure why the
> assume_init() triggered for you but not for me, I don't think has
anything to do
> with doctests since the doctests is in fact just rust code compiled as
KUNIT tests.
I think it's because I wrote separate code that was not a doctest, and
that code is naturally different from however the doctest exercised it.
But it is a good question.
> 
>> Because if you are skipping steps like this (posting the code before
>> there is an actual caller), then the documentation of how to use it
>> is not "just documentation" anymore--it really needs to run
correctly.
> 
> No, that's the thing, these are run. You really are in the wrong here
and appear
> to not understand how doctests work.
That's a reasonable statement. :)
> 
>> 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.

thanks,
-- 
John Hubbard