On Fri, May 05, 2023 at 12:53:41PM +0200, Miguel Ojeda wrote: > On Thu, May 4, 2023 at 10:22 PM Jens Axboe <axboe@xxxxxxxxx> wrote: > > > > Right, but that doesn't really solve the problem when the rust bindings > > get in the way of changes that you are currently making. Or if you break > > them inadvertently. I do see benefits to that approach, but it's no > > panacea. One thing I want to point out is: not having a block layer Rust API doesn't keep the block layer away from Rust ;-) Rust will get in the way as long as block layer is used, directly or indirectly, in any Rust code in kernel. Take the M1 GPU driver for example, it can totally be done without a drm Rust API: Lina will have to directly call C funciton in her GPU driver, but it's possible or she can have her own drm Rust binding which is not blessed by the drm maintainers. But as long as drm is used in a Rust driver, a refactoring/improvement of drm will need to take the usage of Rust side into consideration. Unless of course, some one is willing to write a C driver for M1 GPU. The Rust bindings are actually the way of communication between subsystem mantainers and Rust driver writers, and can help reduce the amount of work: You can have the abstraction the way you like. Of course, there is always "don't do it until there are actually users", and I totally agree with that. But what is a better way to design the Rust binding for a subsystem? * Sit down and use the wisdom of maintainers and active developers, and really spend time on it right now? Or * Let one future user drag the API/binding design to insaneness? I'd rather prefer the first approach. Time spent is time saved. Personally, my biggest fear is: RCU stalls/lockdep warnings in the Rust code (or they don't happen because incorrect bindings), and who is going to fix them ;-) So I have to spend my time on making sure these bindings in good shapes, which is not always a pleasant experience: the more you use something, the more you hate it ;-) But I think it's worth. Of course, by no means I want to force anyone to learn Rust, I totally understand people who want to see zero Rust. Just want to say the maintain burden may exist any way, and the Rust binding is actually the thing to help here. Regards, Boqun > > > > This seems to assume that time is plentiful and we can just add more to > > our plate, which isn't always true. While I'd love to do more rust and > > get more familiar with it, the time still has to be there for that. I'm > > actually typing this on a laptop with a rust gpu driver :-) > > > > And this isn't just on me, there are other regular contributors and > > reviewers that would need to be onboard with this. > > Indeed -- I didn't mean to imply it wouldn't be time consuming, only > that it might be an alternative approach compared to having existing > maintainers do it. Of course, it depends on the dynamics of the > subsystem, how busy the subsystem is, whether there is good rapport, > etc. > > > Each case is different though, different people and different schedules > > and priorities. So while the above is promising, it's also just > > annecdotal and doesn't necessarily apply to our case. > > Definitely, in the end subsystems know best if there is enough time > available (from everybody) to pull it off. I only meant to say that > the security angle is not the only benefit. > > For instance, like you said, the error handling, plus a bunch more > that people usually enjoy: stricter typing, more information on > signatures, sum types, pattern matching, privacy, closures, generics, > etc. > > Cheers, > Miguel
