On 11/27/2025 8:46 AM, Alexandre Courbot wrote:
> On Thu Nov 27, 2025 at 2:10 PM JST, Joel Fernandes wrote:
>>
>>
>> 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.
>
> There is also at least one precedent: the Rust `page_align()` does not
> call a C helper that wraps `PAGE_ALIGN()`, it just reimplements it. I
> think `list_head` is a quite similar situation, but ultimately that's
> for the core team to say.
I don't think a one size/rule fits all will apply for this. We need carefully do
it on a case-by-case basis, for example - if we implement list_add directly in
rust, we'd miss out on CONFIG_LIST_HARDENED. So for that, I will still use the
bindings. For INIT_LIST_HEAD and iteration, it should be Ok, though. So I'll add
that directly in Rust without bindings.
Thanks.
