4 ms·

We mostly agree. I come to a slightly different conclusion. That more than a sales pitch someone needs to lead this project. GKH could decide to build someth

We mostly agree. I come to a slightly different conclusion. That more than a sales pitch someone needs to lead this project. GKH could decide to build something in Rust for instance. Re: whether Drew's proposed solution is a reasonable alternative to Rust for Linux, I don't think the technical/practical reasons for wanting Rust for Linux have gone away. We use Linux. We want memory safety. We will be waiting a long time if we are waiting for a new kernel to appear. > To someone who isn't accustomed to idiomatic Rust, it seems completely insane to have to go digging around in the type system in order to enable magic elsewhere in the call stack, when you can just tell the computer what to do. I think this would be a fairer point if the interface was a well documented C interface, which demonstrated how to use the interface correctly but it wasn't. See the API docs: https://www.kernel.org/doc/html/v6.0/filesystems/api-summary.html#c.iget_locked https://www.kernel.org/doc/html/v6.0/filesystems/api-summary... And the function itself: https://github.com/torvalds/linux/blob/d5d547aa7b51467b15d9caa86b116f8c2507c72a/fs/inode.c#L1360 https://github.com/torvalds/linux/blob/d5d547aa7b51467b15d9c... Ask yourself when and how this can fail. I'm not sure those case are covered here, but they definitely were in the Rust type signature. If these C guys don't like types, fine. But these guys need summon help quick if the above is the best they can do.

stonogo 2y ago
The level of documentation is fairly demonstrably irrelevant. I agree it's garbage, but on the other hand all fifty or so filesystems in the kernel seem to get by without it, and have done for as long as the API has existed. Rust doesn't even have a specification ... still ... a year after deciding one was necessary ... so fingers point both directions here. But even this is a sideshow, a distraction from the main point: these C people are the ones you need to convince. Bitching at them isn't going to make it happen. Until someone sits down and deploys sufficient empathy to figure out how to appeal to their priorities, good things will continue not to happen for Rust-for-Linux. No amount of technical evidence will do the job.
- mustache_kimono 2y ago
  > I agree it's garbage, but on the other hand all fifty or so filesystems in the kernel seem to get by without it, and have done for as long as the API has existed. Have they? I mean what we know from Asahi Lina is that other subsystems need help. That DRM is mostly garbage that needs fixing. > Rust doesn't even have a specification ... still ... a year after deciding one was necessary ... so fingers point both directions here. I'm not sure that's a great example. Especially re: C, with UB all over the place. C says "Sure we have a spec! It doesn't cover that much, and compiler writers are eager as hell to break your bounds checks." > Until someone sits down and deploys sufficient empathy to figure out how to appeal to their priorities, good things will continue not to happen for Rust-for-Linux. No amount of technical evidence will do the job. I think somebody needs to lead this project FFS. Either Linus or GKH. Someone needs to either make it happen or dump it. Screwing around with these Rust devs for years is effed up behavior.

stonogo 2y ago

The level of documentation is fairly demonstrably irrelevant. I agree it's garbage, but on the other hand all fifty or so filesystems in the kernel seem to get by without it, and have done for as long as the API has existed. Rust doesn't even have a specification ... still ... a year after deciding one was necessary ... so fingers point both directions here. But even this is a sideshow, a distraction from the main point: these C people are the ones you need to convince. Bitching at them isn't going to make it happen. Until someone sits down and deploys sufficient empathy to figure out how to appeal to their priorities, good things will continue not to happen for Rust-for-Linux. No amount of technical evidence will do the job.

mustache_kimono 2y ago
> I agree it's garbage, but on the other hand all fifty or so filesystems in the kernel seem to get by without it, and have done for as long as the API has existed. Have they? I mean what we know from Asahi Lina is that other subsystems need help. That DRM is mostly garbage that needs fixing. > Rust doesn't even have a specification ... still ... a year after deciding one was necessary ... so fingers point both directions here. I'm not sure that's a great example. Especially re: C, with UB all over the place. C says "Sure we have a spec! It doesn't cover that much, and compiler writers are eager as hell to break your bounds checks." > Until someone sits down and deploys sufficient empathy to figure out how to appeal to their priorities, good things will continue not to happen for Rust-for-Linux. No amount of technical evidence will do the job. I think somebody needs to lead this project FFS. Either Linus or GKH. Someone needs to either make it happen or dump it. Screwing around with these Rust devs for years is effed up behavior.