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.
