4 ms·

The point is that Rust can model invariants that C can't. You can call both ways, but if C is incapable of expressing what Rust can, that has important implicat

The point is that Rust can model invariants that C can't. You can call both ways, but if C is incapable of expressing what Rust can, that has important implications for the design of APIs which must be common to both.

gwbas1c 2y ago
That's not how I interpreted it: There is a clear need to be able to write filesystems in Rust, and the kernel developer(s) who write the filesystem API don't want to have to maintain the bindings to Rust.
- Smaug123 2y ago
  They say this in almost every paragraph! For example, five of the first seven paragraphs: > The first is to express more of the requirements using Rust's type system in order to catch more mistakes at compile time. > Almeida showed an example of how the Rust type system can eliminate certain kinds of errors. > … it was exactly that kind of discussion/argument that could be avoided by encapsulating the rules into the Rust types and abstractions; the compiler will know the right thing to do. > … All of that is enforced through the type system. > the whole idea is to determine what the constraints are from Viro and other filesystem developers, then to create types and abstractions that can enforce them. More explicitly: > The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs. > As those changes occur, "we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing or a bad thing".
  - gwbas1c 2y ago
    > In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work? Almeida agreed that it was something that needs to be discussed. FWIW: I shipped a Windows file system driver in 2020. The api hadn't changed in years. Does Linux's API for kernel-space filesystems really change so rapidly that keeping the rust bindings up-to-date would be a considerable amount of work, in the long run?

gwbas1c 2y ago

That's not how I interpreted it: There is a clear need to be able to write filesystems in Rust, and the kernel developer(s) who write the filesystem API don't want to have to maintain the bindings to Rust.

Smaug123 2y ago
They say this in almost every paragraph! For example, five of the first seven paragraphs: > The first is to express more of the requirements using Rust's type system in order to catch more mistakes at compile time. > Almeida showed an example of how the Rust type system can eliminate certain kinds of errors. > … it was exactly that kind of discussion/argument that could be avoided by encapsulating the rules into the Rust types and abstractions; the compiler will know the right thing to do. > … All of that is enforced through the type system. > the whole idea is to determine what the constraints are from Viro and other filesystem developers, then to create types and abstractions that can enforce them. More explicitly: > The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs. > As those changes occur, "we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing or a bad thing".
- gwbas1c 2y ago
  > In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work? Almeida agreed that it was something that needs to be discussed. FWIW: I shipped a Windows file system driver in 2020. The api hadn't changed in years. Does Linux's API for kernel-space filesystems really change so rapidly that keeping the rust bindings up-to-date would be a considerable amount of work, in the long run?