6 ms·

I wonder why this feedback came just now and not earlier. It will be time consuming to change now.

tw04 10y ago
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?
- dflock 10y ago
  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. https://lists.freedesktop.org/archives/dri-devel/2016-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
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.
deleted 10y ago
[deleted]

tw04 10y ago

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?

dflock 10y ago
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. https://lists.freedesktop.org/archives/dri-devel/2016-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

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.

deleted 10y ago

[deleted]