5 ms·

> 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

> 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.
  - aseipp 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. "I literally don't even know what I'm talking about at all, I'll admit it -- but definitely, trust me and my immediate assessment of the situation, it's accurate" LOL. >> 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. Are you even reading the words you type? AMD _already has working drivers_. They're right there. You can go look at the code right now, 'git pull' it and install it on your machine. What's stopping you? Your inability to read, apparently? No, it is literally -- by the definition of the above email -- the case that they want to merge already existing code upstream, into the kernel, and have upstream share the maintenance burden. That's part of the deal -- if AMD code goes upstream, everyone helps maintain it, and in turn, they help maintain everyone elses. But it turns out, upstream doesn't want their code in its current state. Of course, they don't have to merge it upstream -- they just want to. They don't even have to merge it upstream now or "soon", but they would have liked that. They could easily ship the AMDGPU driver as an external module using DKMS or something, just as things like ZFS-on-Linux do, and start ironing out problems for upstreamability while actually shipping drivers to people. They have drivers. The drivers work already, in fact. Having them upstream is totally different. Try reading the article and doing some digging through this thread to understand the context. > 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. You realize that given AMD's history -- it's entirely possible AMD needs Linux more than Linux needs AMD, right? Linux doesn't need to win the desktop or win over AMD, it thrives in its own market and has been surviving perfectly well without them.

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.
- aseipp 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. "I literally don't even know what I'm talking about at all, I'll admit it -- but definitely, trust me and my immediate assessment of the situation, it's accurate" LOL. >> 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. Are you even reading the words you type? AMD _already has working drivers_. They're right there. You can go look at the code right now, 'git pull' it and install it on your machine. What's stopping you? Your inability to read, apparently? No, it is literally -- by the definition of the above email -- the case that they want to merge already existing code upstream, into the kernel, and have upstream share the maintenance burden. That's part of the deal -- if AMD code goes upstream, everyone helps maintain it, and in turn, they help maintain everyone elses. But it turns out, upstream doesn't want their code in its current state. Of course, they don't have to merge it upstream -- they just want to. They don't even have to merge it upstream now or "soon", but they would have liked that. They could easily ship the AMDGPU driver as an external module using DKMS or something, just as things like ZFS-on-Linux do, and start ironing out problems for upstreamability while actually shipping drivers to people. They have drivers. The drivers work already, in fact. Having them upstream is totally different. Try reading the article and doing some digging through this thread to understand the context. > 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. You realize that given AMD's history -- it's entirely possible AMD needs Linux more than Linux needs AMD, right? Linux doesn't need to win the desktop or win over AMD, it thrives in its own market and has been surviving perfectly well without them.