Re: Rust kernel policy

[Miguel Ojeda]

On Thu, Feb 20, 2025 at 5:03 PM James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> OK, this is just a terminology difference.  I think of bindings as the
> glue that sits between two pieces of code trying to interact.  In your
> terms that's both the abstractions and the bindgen bindings.

Ah, got it, thanks. I was confused by the "headers" bit, because I
didn't know if you were referring to the C ones or the Rust "headers".

> You say that like it's easy ... I think most people who work in the
> kernel wouldn't know how to do this.

Yeah, in the general case, one needs to know Rust and how the safe
abstraction is designed. I only meant in simple cases like the "gains
a parameter" I was giving as an example.

> I'm under no illusion that this would be easy, but if there were a way
> of having all the information required in the C code in such a way that
> something like an extended sparse could check it (so if you got the
> annotations wrong you'd notice) and an extended bindgen could generate
> both the bindings and the abstractions from it, it would dramatically
> reduce the friction the abstractions cause in kernel API updates.

Yeah, it would definitely be amazing to have. Nevertheless, I think
annotating C headers is still something we should do as much as
reasonably possible, even if it does not lead to full generation. Even
if Rust was not a thing, it would also be helpful for the C side on
its own.

> Yes, I think it does, thanks.

You're welcome!

Cheers,
Miguel