5 ms·

It seems like they might have somehow ignored direction from as early as February... https://lists.freedesktop.org/archives/dri-devel/2016-February/100566.html

by pero 10y ago

It seems like they might have somehow ignored direction from as early as February... https://lists.freedesktop.org/archives/dri-devel/2016-February/100566.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

aidenn0 10y ago
Even more clear: > 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-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
- wolfgke 10y ago
  > 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).
  - deleted 10y ago
    [deleted]
  - pas 10y ago
    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.
mackal 10y ago
This is why Linus swears. The message that their current path wouldn't have fallen on deaf ears if he chews them out.
- partycoder 10y ago
  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.

by pero 10y ago

aidenn0 10y ago

Even more clear: > 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-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

wolfgke 10y ago
> 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).
- deleted 10y ago
  [deleted]
- pas 10y ago
  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.

mackal 10y ago

This is why Linus swears. The message that their current path wouldn't have fallen on deaf ears if he chews them out.

partycoder 10y ago
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.