On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote: > On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote: > > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote: > > > Anyway, that's all hand-wavy right now, sorry, to get back to the point > > > here, again, let's take this, which will allow the firmware bindings to > > > be resubmitted and hopefully accepted, and we can move forward from > > > there to "real" things like a USB or PCI or even platform device and > > > driver binding stuff. > > > > In order to continue I propose to send out the following series: > > > > 1) minimal device and firmware abstractions only > > Sounds good. Just a heads-up, I'll probably send this one quite a bit earlier than the other two to make sure to unblock Fujita on their PHY driver. > > But after this, I don't want to take ANY driver core rust code that is > not able to live in the "normal" part of the Linux kernel tree. It's > just unsustainable to have it all in one directory sorry. If this > deadline makes that kbuild work actually happen faster, all the more > reason to have it. If that kbuild work is somehow stalled due to other > issues, please let me know what that is. > > > 2) v2 of all other device / driver, devres and PCI driver abstractions > > I will be glad to review this. Glad to hear that! > > > 3) v2 of basic DRM driver abstractions and Nova > > I love it how one of the most complex driver subsystems we have (drm) is > attempting to be the "first real" driver use for the rust apis. Bold > move :) I'd argue that as one of the most complex driver subsystems we have a lot of need for the advantages Rust provides to us. :) > > > The v2 series would contain static driver allocation (in case of DRM even const) > > and quite a few more simplifications around `driver::Registration` and > > `device::Data`. > > > > Does that make sense? > > Yes, but note, I'm going to probably push back on the "driver::" stuff. That's OK, I'm happy to convince you of its usefulness. :) > But will do so with more constructive criticism as I want this to work > very much and I agree that I think we are both talking past each other > in different ways. Mostly probably due to my total lack of Rust > experience, my apologies, thanks for your patience with me for this. Very much appreciated! Please don't hesitate to ask for more explanation on certain things if they're unclear. I'm happy trying my best to provide useful answers. - Danilo > > thanks, > > greg k-h >
