> On Nov 29, 2025, at 5:44 PM, John Hubbard <[email protected]> wrote: > > On 11/28/25 1:49 PM, Joel Fernandes wrote: >>> On 11/27/2025 8:46 AM, Alexandre Courbot wrote: >>> On Thu Nov 27, 2025 at 2:10 PM JST, Joel Fernandes wrote: > ... >>> 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 > > Case-by-case is certainly a good way to evaluate these things, yes. > >> 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. > > Here, I'm not so sure that even this case is a solid one. Because > CONFIG_LIST_HARDENED is a way for C code to help protect against > list corruption--which is generally going to come from the C side, > not the Rust side, for the most part. > > Let the C code have its extra checks, but on the Rust side we can > either add them, or skip them--but I don't think we need to *invoke* > them via the C code.
I think we do. This is a C list abstraction (rust interacting with C-side code, the list_head comes from C bindings). If we want a pure rust list, we should not be using clist in the first place. There is list.rs for that. Imagine C and rust both adding items to a C list but one is having debugging code but the other does not. That is really weird. Thanks. > > > > thanks, > -- > John Hubbard >
