Nouveau - Nov 2025 - [PATCH v2 1/3] rust: helpers: Add list helpers for C linked list operations

On 11/26/25 10:50 AM, Joel Fernandes wrote:
>> On Nov 25, 2025, at 8:16?PM, Alexandre Courbot <acourbot at
nvidia.com> wrote:
>> ?On Wed Nov 26, 2025 at 3:16 AM JST, Joel Fernandes wrote:
>>>>> On Nov 25, 2025, at 9:52?AM, Alexandre Courbot <acourbot
at nvidia.com> wrote:
>>>> ?On Wed Nov 12, 2025 at 2:13 AM JST, Joel Fernandes wrote:
...
> You do have a point that we have an abstraction leak anyway, so the
question is do we need helpers at all.
>
I'm writing this in order to suggest a stance in this area, for future
feature tradeoffs. If this is somehow "off", I'll upgrade my
thinking,
but at the moment I'm very comfortable making the following claims:

 
> I am torn on this. On the one hand, if someone changes how list_head api
works, then the rust side breaks
OK, this is not going to happen, at list not without a truly epic, long-term
effort, accompanied by *lots* of publicity. The list_head API is just too
foundational to change easily.

It's been stable since *at least* 2006. The only change since then has been
to add WRITE_ONCE() wrappers to the INIT_LIST_HEAD implementation--and that
is not an API change.

Anything is possible, but this is sufficiently far out there that it should
not count for much here.

(though that is easy to flag though via doc tests). On the other hand, we have
the function call overhead you pointed and we are dealing with the pointers in
rust directly anyway in some cases.

Whereas this is very significant! We really, really do not want to accept
a performance loss vs. C, without an excellent justification.

So I think you've made the right decision. The above is just to help
solidify the reasons why.


thanks,
-- 
John Hubbard

On 11/26/2025 3:57 PM, John Hubbard wrote:
>  
>> I am torn on this. On the one hand, if someone changes how list_head
api works, then the rust side breaks
> OK, this is not going to happen, at list not without a truly epic,
long-term
> effort, accompanied by *lots* of publicity. The list_head API is just too
> foundational to change easily.
> 
> It's been stable since *at least* 2006. The only change since then has
been
> to add WRITE_ONCE() wrappers to the INIT_LIST_HEAD implementation--and that
> is not an API change.
> 
> Anything is possible, but this is sufficiently far out there that it should
> not count for much here.
> 
> (though that is easy to flag though via doc tests). On the other hand, we
have the function call overhead you pointed and we are dealing with the pointers
in rust directly anyway in some cases.
> 
> Whereas this is very significant! We really, really do not want to accept
> a performance loss vs. C, without an excellent justification.
> 
> So I think you've made the right decision. The above is just to help
> solidify the reasons why.
Yeah, these are good points. Thanks John.

 - Joel

> On 26 Nov 2025, at 17:57, John Hubbard <jhubbard at nvidia.com>
wrote:
> 
> On 11/26/25 10:50 AM, Joel Fernandes wrote:
>>> On Nov 25, 2025, at 8:16?PM, Alexandre Courbot <acourbot at
nvidia.com> wrote:
>>> ?On Wed Nov 26, 2025 at 3:16 AM JST, Joel Fernandes wrote:
>>>>>> On Nov 25, 2025, at 9:52?AM, Alexandre Courbot
<acourbot at nvidia.com> wrote:
>>>>> ?On Wed Nov 12, 2025 at 2:13 AM JST, Joel Fernandes wrote:
> ...
>> You do have a point that we have an abstraction leak anyway, so the
question is do we need helpers at all.
>> 
> 
> I'm writing this in order to suggest a stance in this area, for future
> feature tradeoffs. If this is somehow "off", I'll upgrade my
thinking,
> but at the moment I'm very comfortable making the following claims:
> 
> 
>> I am torn on this. On the one hand, if someone changes how list_head
api works, then the rust side breaks
> 
> OK, this is not going to happen, at list not without a truly epic,
long-term
> effort, accompanied by *lots* of publicity. The list_head API is just too
> foundational to change easily.
> 
> It's been stable since *at least* 2006. The only change since then has
been
> to add WRITE_ONCE() wrappers to the INIT_LIST_HEAD implementation--and that
> is not an API change.
> 
> Anything is possible, but this is sufficiently far out there that it should
> not count for much here.
> 
> (though that is easy to flag though via doc tests). On the other hand, we
have the function call overhead you pointed and we are dealing with the pointers
in rust directly anyway in some cases.
> 
> Whereas this is very significant! We really, really do not want to accept
> a performance loss vs. C, without an excellent justification.
JFYI, and let me preface this by saying I know little about NVIDIA hardware:
this overhead
had very little impact on the Rust Arm Mali driver.
> 
> So I think you've made the right decision. The above is just to help
> solidify the reasons why.
> 
> 
> thanks,
> -- 
> John Hubbard
> 
> 
? Daniel