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