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. 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. > 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 :) > 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. 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. thanks, greg k-h
