AMD is trying to merge a Windows driver with enough shims to make it sort of interact with Linux. That might as well be written in Brainfuck from the point of view of a Linux kernel hacker trying to figure out WTF it does.

To merge a driver into the kernel is to accept responsibility for maintaining it, which they recognize they are not prepared or even interested in doing.

They've made it clear that this code doesn't come from the Windows driver, it was specifically written with the intention of being usable on any platform. Also, they seem quite willing to maintain it. The problem is that the Linux developers aren't willing to merge code that's usable on anything other than Linux.

Thanks for the correction. They aren't relying upon a Windows API that Linux kernel hackers have no experience with, but instead a new API that nobody has experience with. That's still a huge problem for the maintenance that in-kernel drivers need; they can't have a driver which only one company understands.

This was pitched by AMD as "Yeah, our new proprietary driver can use the same kernel stub as the libre driver" with minor modifications a year ago, and instead what was delivered was a giant HAL that only AMD can maintain. I get why its not being mainlined, this is AMD's screwup.

> I can respect your technical points and if you kept it to that, I'd be fine with it and we could have a technical discussion starting there.

Why is that so unreasonable?

By the look of it, he's trying to be reasonable now; after half a year of hope that the code will just get checked in because it's coming from AMD, regardless of quality.

If I recall correctly, Google tried the same thing some time ago and it didn't go well for them either.