Re: [PATCH v2 1/3] rust: helpers: Add list helpers for C linked list operations

[John Hubbard <jhubbard@nvidia.com>]

On 11/26/25 10:50 AM, Joel Fernandes wrote:
>> On Nov 25, 2025, at 8:16 PM, Alexandre Courbot <acourbot@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@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