> 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.
> 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.
But abstracting all this is fitting the infrastructure to their needs (which is having a common driver infrastructure for many operating systems).
Sure, but then why not just continue with the binary blob?
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.
Well, there are ways to make a point and emphasizing an idea without resorting to swearing. The Linux kernel project has lost some maintainers because of this.
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.
Exactly what I'm wondering since they've been working on this for quite some time and asked for feedback a long time ago. How do you sit on this until they are this far along?
They've been getting this feedback - and apparently ignoring it - since February:
> 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.
It will be time consuming to change now.