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

[John Hubbard <jhubbard@nvidia.com>]

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.

I would humbly suggest that you build and *run* your own samples code, for
new code that has no users yet.

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.

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?

...
>> The fix requires two-step initialization, like this, for example:
> 
> It has nothing to do with 2-step initialization. The issue is only related to
> the HEAD (and not the items) right? The issue is `assume_init()` should not be
> used on self-referential structures, the fix just one line:
> 
> -//! # unsafe { init_list_head(head.as_mut_ptr()) };
> -//! # let mut head = unsafe { head.assume_init() };
> 
> +//! # let head = head.as_mut_ptr();
> +//! # unsafe { init_list_head(head) };
> 
> Does that fix the issue in your private sample test too?
> 
> Or did I miss what you're suggesting?
> 

Yes, you are correct: the main point is to avoid moving a struct
that contains self-referential fields. So your version is a more
accurate and better fix.

...
>>> +pub struct Clist<'a, T> {
>>> +    head: &'a ClistHead,
>>> +    offset: usize,
>>> +    _phantom: PhantomData<&'a T>,
>>> +}
>>
>> This discards build-time (const generic) information, and demotes it to 
>> runtime (.offset), without any real benefit. I believe it's better to keep
>> it as a const generic, like this:
>>
>> pub struct Clist<'a, T, const OFFSET: usize> {
>>     head: &'a ClistHead,
>>     _phantom: PhantomData<&'a T>,
>> }
>>
>>> +
>>> +impl<'a, T> Clist<'a, T> {
>>
>> And here, the above becomes:
>>
>> impl<'a, T, const OFFSET: usize> Clist<'a, T, OFFSET> {
>>
>> ...etc.
> 
> It is not ignored, the const-generic part only applies to the constructor method
> in my patch. I didn't want to add another argument to the diamond brackets, the
> type name looks really ugly then.
>

The macro hides it, though. Users never have to write the full type.

Increasing const-ness is worth something. The messy syntax is unfortunate,
but I don't really know what to say there. 

 
> The only advantage I think of doing this (inspite of the obvious aesthetic
> disadvantage) is that a mutable `Clist` cannot have its offset modified. Let me
> see if I can get Alice's suggestion to make it a const in the struct work to
> solve that.

Yes. I have it working locally, so I'm confident that you will prevail. :)


thanks,
-- 
John Hubbard