> On 26 Nov 2025, at 17:57, John Hubbard <[email protected]> wrote:
>
> On 11/26/25 10:50 AM, Joel Fernandes wrote:
>>> On Nov 25, 2025, at 8:16 PM, Alexandre Courbot <[email protected]> wrote:
>>> On Wed Nov 26, 2025 at 3:16 AM JST, Joel Fernandes wrote:
>>>>>> On Nov 25, 2025, at 9:52 AM, Alexandre Courbot <[email protected]>
>>>>>> 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
