I am not familiar at all with this stuff but honestly people should be working on a way to isolate external code in the kernel at runtime somehow.
I wouldnt want to be in either position, I dont want to maintain somebody else's shitty code or get any kind of bugs for my own code from it but I also wouldnt want to be in AMDs position and adhere or rewrite some code that I'm absolutely fine with as it is.
There is a lack of a project vision if people reject code that would otherwise lead to great "commercial" aka user adoption success. The maintainers are understandably reluctant to accept new code, especially if it doesnt even try to adhere to the coding standards.
He even acknowledged the political situation but it wasnt even his job to care about that.
There needs to be somebody over him who's job it is to make him accept that code or figure out a better solution.
The problem isn't runtime isolation. The problem is that if you merge a Windows driver into the Linux kernel, the Linux hackers won't be able to make effective and safe changes to it as the rest of the kernel evolves, because it's nearly unreadable to them.
An unmaintainable mess with lots of users is not a victory unless users are paying you for shitty work.
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.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
