I wonder why this feedback came just now and not earlier.
It will be time consuming to change now.
It will be time consuming to change now.
https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
> Cleaning up that is not enough, abstracting kernel API like kmalloc or i2c, or similar, is a no go. If the current drm infrastructure does not suit your need then you need to work on improving it to suit your need. You can not develop a whole drm layer inside your code and expect to upstream it.
https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
But abstracting all this is fitting the infrastructure to their needs (which is having a common driver infrastructure for many operating systems).
Kernel development is largely an optimization process of the internal model of what a kernel should do, and for that developers need first-class raw data, the DRM maintainer wants to know how you'd like to change DRM. And though you can put that into a translation/abstraction layer, it's not helpful, because that doesn't scale, because the maintainer would have to look at every such layers and come up with a common one, and repeat this grueling task every time they want to move forard with DRM itself.
Now to be fair, one merit of Linus is that he is direct and says he doesn't like something, and not weasel language like "maybe later" or other time-wasting expressions that force people to guess what he is thinking.
> Cleaning up that is not enough, abstracting kernel API like kmalloc or i2c, or similar, is a no go. If the current drm infrastructure does not suit your need then you need to work on improving it to suit your need. You can not redevelop a whole drm layer inside your code and expect to upstream it.
> Linux device driver are about sharing infrastructure and trying to expose it through common API to userspace.
> So i strongly suggest that you start thinking on how to change the drm API to suit your need and to start discussions about those changes. If you need them then they will likely be usefull to others down the road.
https://lists.freedesktop.org/archives/dri-devel/2016-Februa...