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
