On Fri, May 05, 2023 at 05:24:56AM -0700, Boqun Feng wrote: > 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? > Ah, of course, I should add: this is not the usual case, most of the time, users (e.g. a real driver) can help the design, I was just trying to say: without the wisdom of maintainers and active developers, a Rust binding solely designed by one user could have some design issues. In other words, the experience of maintaining C side API is very valuable to design Rust bindings. Regards, Boqun > 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
