4 ms·

Runtime isolation would absolutely solve that problem, it would safely shift the blame to AMD if the thing becomes broken. Without it, the kernel devs now have

Runtime isolation would absolutely solve that problem, it would safely shift the blame to AMD if the thing becomes broken. Without it, the kernel devs now have to maintain more and more code that they probably dont know anything about. I dont see how that can possibly be a good solution. I dont see how anyone can even argue that. Why should a 3rd party graphics driver NOT be a plugin instead of core code? Stupidly obvious to make this an isolated plugin.

prodigal_erik 10y ago
The whole point of putting drivers in the kernel tree is that they get properly maintained as part of kernel development. All the kernel hackers are responsible for keeping all the in-kernel drivers working. If it's at all acceptable for a kernel change to break a driver with no fix, that driver doesn't belong in the kernel tree.
- hubert123 10y ago
  The whole point of plugins is that they dont need to be maintained as part of the core product. Seeing AMD's response, it's obvious that they dont expect Linux kernel devs to maintain this thing. They should offer a proper and easy plugin interface for the kernel where devs can make drivers for it without having to merge code into the kernel itself. This really seems too obvious, at some point the kernel will have too much code, will have to support too many different pieces of new hardware to be understood or maintained by anybody. I'm sure Windows doesnt merge 3rd party graphics driver code into their subversion repo, that would be insane. But just because Linux is open source, it has to do that.. no of course not.
  - chris_wot 10y ago
    They do already have clear interfaces that do this. Some modules have less clear interfaces, but if you followed what they were saying they actually said that it would have been easier if they had subclassed some of the code and followed the way that most folks were writing atomic code. And there was a function with the bane "validate" that didn't, well, validate. In a bit of code that rung alarm bells.
    - wtallis 10y ago
      An email from one of the Intel devs clarified that the validation was actually happening in the correct place, it just was hard to see that on first reading because the code was too foreign: > And by following that pattern (and again you can store whatever you want in your own private dc_surface_state) it makes it really easy for others to quickly check a few things in your driver, and I wouldn't have made the mistake of not realizing that you do validate the state in atomic_check. https://lists.freedesktop.org/archives/dri-devel/2016-December/126698.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...
    - hubert123 10y ago
      > And there was a function with the bane "validate" that didn't, well, validate so what? you still dont seem to grasp the concept of plugins. Plugin = the 3rd party developer can do whatever he wants and it doesnt hurt the core product.
      - chris_wot 10y ago
        You say "so what", but that is the so what. A core Linux developer saw a massive commit come though from AMD and couldn't understand it easily. The point that has been made over and over in these threads is that if you want to develop Linux code then you can't just stick a development team to work in complete isolation from everyone else in the Linux development community and expect to be able submit grand unifying architectures you designed to make it easier for your company but that make it harder for everyone else. If you want to do this, then you really need to work within this particular community to effect change. For instance, there apparently are some standard idioms that have emerged from within the atomic code. The way AMD have done things is different enough to confuse the core maintainer, and he has reasonably said that he doesn't want to accept a commit like this. Hence his comments about the HAL and a massive middleware layer. The bottom line is: AMD want to merge this into the kernel's main tree. But if they want to do this, they have to get through the maintainers, and the maintainers have to consider the whole picture and notjust your team, no matter how hard they have worked on their code. The AMD team seem to have worked in a silo, not released to the CI servers and from what I'm reading broke stuff that others then fixed. So when the AMD guys did a big release all at once like this, then they got told - politely! - that their code wasn't up to scratch.
  - deleted 10y ago
    [deleted]
  - prodigal_erik 10y ago
    Linux has supported separately compiled kernel modules for decades. If kernel developers are not expected to maintain this code, it need not and should not be merged into the kernel source tree. Windows presents an API to drivers that's very painful for them to change. This is a problem that Linux can avoid by not treating drivers as black boxes.

prodigal_erik 10y ago

The whole point of putting drivers in the kernel tree is that they get properly maintained as part of kernel development. All the kernel hackers are responsible for keeping all the in-kernel drivers working. If it's at all acceptable for a kernel change to break a driver with no fix, that driver doesn't belong in the kernel tree.

hubert123 10y ago
The whole point of plugins is that they dont need to be maintained as part of the core product. Seeing AMD's response, it's obvious that they dont expect Linux kernel devs to maintain this thing. They should offer a proper and easy plugin interface for the kernel where devs can make drivers for it without having to merge code into the kernel itself. This really seems too obvious, at some point the kernel will have too much code, will have to support too many different pieces of new hardware to be understood or maintained by anybody. I'm sure Windows doesnt merge 3rd party graphics driver code into their subversion repo, that would be insane. But just because Linux is open source, it has to do that.. no of course not.
- chris_wot 10y ago
  They do already have clear interfaces that do this. Some modules have less clear interfaces, but if you followed what they were saying they actually said that it would have been easier if they had subclassed some of the code and followed the way that most folks were writing atomic code. And there was a function with the bane "validate" that didn't, well, validate. In a bit of code that rung alarm bells.
  - wtallis 10y ago
    An email from one of the Intel devs clarified that the validation was actually happening in the correct place, it just was hard to see that on first reading because the code was too foreign: > And by following that pattern (and again you can store whatever you want in your own private dc_surface_state) it makes it really easy for others to quickly check a few things in your driver, and I wouldn't have made the mistake of not realizing that you do validate the state in atomic_check. https://lists.freedesktop.org/archives/dri-devel/2016-December/126698.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...
  - hubert123 10y ago
    > And there was a function with the bane "validate" that didn't, well, validate so what? you still dont seem to grasp the concept of plugins. Plugin = the 3rd party developer can do whatever he wants and it doesnt hurt the core product.
    - chris_wot 10y ago
      You say "so what", but that is the so what. A core Linux developer saw a massive commit come though from AMD and couldn't understand it easily. The point that has been made over and over in these threads is that if you want to develop Linux code then you can't just stick a development team to work in complete isolation from everyone else in the Linux development community and expect to be able submit grand unifying architectures you designed to make it easier for your company but that make it harder for everyone else. If you want to do this, then you really need to work within this particular community to effect change. For instance, there apparently are some standard idioms that have emerged from within the atomic code. The way AMD have done things is different enough to confuse the core maintainer, and he has reasonably said that he doesn't want to accept a commit like this. Hence his comments about the HAL and a massive middleware layer. The bottom line is: AMD want to merge this into the kernel's main tree. But if they want to do this, they have to get through the maintainers, and the maintainers have to consider the whole picture and notjust your team, no matter how hard they have worked on their code. The AMD team seem to have worked in a silo, not released to the CI servers and from what I'm reading broke stuff that others then fixed. So when the AMD guys did a big release all at once like this, then they got told - politely! - that their code wasn't up to scratch.
- deleted 10y ago
  [deleted]
- prodigal_erik 10y ago
  Linux has supported separately compiled kernel modules for decades. If kernel developers are not expected to maintain this code, it need not and should not be merged into the kernel source tree. Windows presents an API to drivers that's very painful for them to change. This is a problem that Linux can avoid by not treating drivers as black boxes.