3 ms·

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

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.
    - hubert123 10y ago
      I'm not arguing with you over what they did, I have not read about it enough. I didn't even read the the exchange in full. This is purely political and a sign of a lack of leadership. The Linux guys should be so grateful for these drivers that they do everything they can to keep AMD happy. > 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 that's a problem for Linux > The bottom line is: AMD want to merge this into the kernel's main tree No, AMD wants to have working AMD drivers on Linux. It's more than likely that they were told to do it this way and this way sucks. A lot. But hell, maybe Linux devs think that Linux is so important now that they can pressure AMD devs into doing whatever they want from them. Maybe it works, maybe it wont.
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.

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.
  - hubert123 10y ago
    I'm not arguing with you over what they did, I have not read about it enough. I didn't even read the the exchange in full. This is purely political and a sign of a lack of leadership. The Linux guys should be so grateful for these drivers that they do everything they can to keep AMD happy. > 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 that's a problem for Linux > The bottom line is: AMD want to merge this into the kernel's main tree No, AMD wants to have working AMD drivers on Linux. It's more than likely that they were told to do it this way and this way sucks. A lot. But hell, maybe Linux devs think that Linux is so important now that they can pressure AMD devs into doing whatever they want from them. Maybe it works, maybe it wont.

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.