On Thu, May 4, 2023 at 9:02 PM Jens Axboe <axboe@xxxxxxxxx> wrote: > > But back to the real question... This is obviously extra burden on > maintainers, and that needs to be sorted out first. Block drivers in Regarding maintenance, something we have suggested in similar cases to other subsystems is that the author gets involved as a maintainer of, at least, the Rust abstractions/driver (possibly with a different `MAINTAINERS` entry). Of course, that is still work for the existing maintainer(s), i.e. you, since coordination takes time. However, it can also be a nice way to learn Rust on the side, meanwhile things are getting upstreamed and discussed (I think Daniel, in Cc, is taking that approach). And it may also be a way for you to get an extra maintainer/reviewer/... later on for the C parts, too, even if Rust does not succeed. > general are not super security sensitive, as it's mostly privileged code > and there's not a whole lot of user visibile API. And the stuff we do > have is reasonably basic. So what's the long term win of having rust > bindings? This is a legitimate question. I can see a lot of other more > user exposed subsystems being of higher interest here. >From the experience of other kernel maintainers/developers that are making the move, the advantages seem to be well worth it, even disregarding the security aspect, i.e. on the language side alone. Cheers, Miguel
