[X86BSD]

That's an interesting take from someone who develops a kernel that the rest of the world has to rip out all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform. Jesus the hypocrisy is deep.

[AsyncAwait]

So Linux is not allowed to demand quality code that is following their conventions and has to be satisfied with the minimum amount of effort for AMD's Windows code to run? Why should the Linux kernel include an abstraction layer for AMD's Windows code? Why would any sane person agree to that?

> all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform.

If you're developing for Linux, using Linux specific technology, then of course there would be porting effort required.

Same as if you want to make you Windows stuff work on Linux, there should be porting required - after all, it's a different platform,

What AMD wants to do is to sidestep as much of the porting as possible, by effectively shipping their Windows code inside the Linux kernel.

[wolfgke]

> So Linux is not allowed to demand quality code that is following their conventions and has to be satisfied with the minimum amount of effort for AMD's Windows code to run? Why should the Linux kernel include an abstraction layer for AMD's Windows code? Why would any sane person agree to that?

Linux is open source, so if the kernel developers desire better designed code, they are free to change the code up to their quality levels. If the kernel development team does not have the manpower for this, they should better think about a way to maintain the kernel that involves less work. One example (among many) would be to think about a way to keep the internal kernel interfaces typically stable over many years so that only rarely there is a lot work to be done for updating all the drivers to the new internal kernel interfaces.

> If you're developing for Linux, using Linux specific technology, then of course there would be porting effort required.

The released open source drivers seem to work quite well (as they do on Windows). The problem is that they don't fit the taste of the kernel developers.

[AsyncAwait]

> Linux is open source

Open source does not mean, "any code accepted here!"

> if the kernel developers desire better designed code, they are free to change the code up to their quality levels.

They are also free to reject bad code and demand that if you want you code in, you should improve it.

I don't get this mentality at all; why should the kernel developers accept inferior code and then improve it? Isn't that the responsibility of the vendor who designed the product? After all, AMD is a for profit company, not a charity. Why should the other developers provide charity to make AMD code better? So that AMD can sell more units or have better PR? What?

>The problem is that they don't fit the taste of the kernel developers.

That's not the problem.

The problem is that the drivers were designed for Windows, not Linux and such code is not suitable for inclusion in the Linux kernel.

[quickben]

Anything that breaks transactional states and atomicity isn't 'fit the taste', it's getting fired and we'll get somebody that can do those properly.

If anything, that post highlights the lack of quality among the amd driver team, and doesn't have to do much with 'taste'.

[makomk]

If I'm following the conversation correctly, it doesn't break anything, the kernel developers don't understand it. Also, the followup from Alex Deucher of the AMD team is interesting: https://lists.freedesktop.org/archives/dri-devel/2016-Decemb... Basically, he reckons that the atomic modesetting code is a poorly-thought out and maintained disaster that regularly breaks multiple drivers - and having somewhat followed the changelogs, I can entirely believe this. (Dave Airlie responds by blaming AMD for not sufficiently testing the upstream kernel developers' buggy changes to their drivers.)

[quickben]

You are probably right. But so are the kernel devs.

It seems to be an argument of: we do this for all drivers, vs amd pushing: we want to be the exception for this driver only.

[aseipp]

> If the kernel development team does not have the manpower for this, they should better think about a way to maintain the kernel that involves less work.

Or, they could have AMD do the work, since apparently they're the ones who didn't listen -- after being told months ago -- that this rejection could happen when they tried to include a HAL with their driver. I think that perfectly works: the kernel developers don't have to "do all that work" involving un-fucking AMD's driver, and AMD instead has to do the work. Sounds good to me.

There's literally 0 point in accepting the code as-is, because everyone would be on the hook for maintenance it in the mean time, while it got un-crappified, and it would make graphics subsystem maintainers life worse. No. Kick it out, make them do it the right way, and when they come back -- they can talk.

This whole thread has got plenty of of entitled whiners and people with a bone-to-pick against Linux, like yourself, bitching,about OSS maintainers not making their own lives harder because you want feel good about your graphics driver. Get over it. Or, get involved -- maybe you could send a few patches to AMD maintainers to clean out some of the crap.

AMD is not being banned from kernel development, but they're going to have to do it right. Just like the other 20-30 companies that regularly contribute upstream to Linux with their money/developers.

In fact, Linux often accepts drivers for hardware that only certain companies have access to and are of no use to anyone else in the general public. Why? Because they played by the rules, meaning the overall maintenance cost to include those drivers becomes far smaller in the long run. The cost of including the AMDGPU driver, as it is now, is astronomically high in comparison.

> The released open source drivers seem to work quite well (as they do on Windows). The problem is that they don't fit the taste of the kernel developers.

No. Let's be clear: the problem is AMD can't listen, and people like you apparently, can't read. That's about all it comes down to. You are free to now whine and complain about how incredibly important this is and how it's definitely worth breaking the rules over and how much it means to you, and I'm sure the kernel developers owe you this feature, or something (after all, developers are just robots with no lives and if they don't work hard enough, they're bad.)

Meanwhile, it will be ignored, Linux will go on (and continue to crush its competitors in the spaces it matters in), and the world will still turn. And maybe in a year from now AMD will actually have something worth merging. In the mean time, Nvidia will continue to dominate them in the compute market. Maybe actually listening 9 months ago would have saved them some time and market share.

[pcwalton]

> In the mean time, Nvidia will continue to dominate them in the compute market. Maybe actually listening 9 months ago would have saved them some time and market share.

NVIDIA is about the furthest thing from a shining example of good behavior in the Linux kernel. By not having open source drivers at all, they're far worse.

(By the way, their closed source driver has a HAL too.)

[msbarnett]

Yeah, this seems like the kernel devs are making the classic "the perfect is the enemy of the good" mistake.

They're sending the message that AMD would be better off shipping closed source drivers, like Nvidia, because that would save them the headache of trying to get their merely good but not perfect open source drivers into the hands of users via dealing with Kernel politics.

But then again, what else is new.

[Drdrdrq]

I don't think there is much difference between blob and such code from the kernel maintainers' point of view. From users' point of view the difference is huge (freedom to tinker / fix bugs), but maintainers need to keep the whole kernel maintainable. Merging such code would be irresponsible.

And no, I don't want just "good" code in kernel I am using. This is not business. Make it maintainable so it can get better (perfect) in the long run. (yes, I know there are places in kernel where code is not even good, let alone perfect, but that's another issue altogether)

[IntelMiner]

The thing is though, if they shipped a driver like Nvidia does, where it's this blob that just wraps its tendrils into what ever systems are needed, that's not the graphics maintainers problem either

It's a net loss for users of AMD hardware (though AMD's hardware on Linux has been a dumpster fire for as long as I can remember) because they have to suffer arguably worse driver support, but that's on AMD for wanting to have their cake and eat it too

[eVeechu7]

If someone writes application software that depends on the linux kernel, and someone else wants to port that code to another platform, how is the fact that code changes are required the fault of the kernel developers? I don't see any hypocrisy.

[dom0]

I feel X86BSD here, because Linux has a history of being different for the sake of being different. A relatively recent example could be getentropy (BSD) vs getrandom (Linux).

OTOH Linux has some extremely useful syscalls that others just don't have, sometimes causing major performance regressions. Case in point: sync_file_range.

But then Linux also has a history of screwing up and having a bunch of different syscalls on different platforms because somebody introducing a syscall didn't quite think it through. Case in point: sync_file_range. This "only" causes extra work for developers directly working with syscalls - so usually libc devs.

[AsyncAwait]

Linux is Linux.

BSD is BSD

Windows also has different sys calls than both Linux and BSD, that's because it's a different OS.

Yes, there's POSIX in there, but generally it is its own OS and you need to treat is as such, same as Windows really.

[raverbashing]

Yes, and this discussion makes perfect sense on user level code.

Yes, Linux, Mac OSX and BSDs have their differences.

But in the kernel, code is going to (or even has to) be less generic

[fithisux]

Not if you choose a uKernel design and para virtualize the legacy OSes.

[aseipp]

That's a nice computer science project but ultimately irrelevant in the context of kernel mode drivers, for like 99.99% of people who use Linux.

Not that tiny hypervisors and stuff aren't cool, though.

[dom0]

Indeed

[jordigh]

> because Linux has a history of being different for the sake of being different.

Heh.

I get the same feeling about git when I'm working with hg, the Canada[1] of git. For svn, darcs, bzr, and Mercurial, "revert" means to change the working directory to the repo state. Why did git use it to mean creating a new commit that undoes an old commit?

There's no use rallying against the majority software when it doesn't follow the standard. When you're the majority, you just get to make your own standards because you are the standard. BSD being the Canada of Linux, it's a little funny to hear them complaining about things that Linux does.

--

[1] http://itre.cis.upenn.edu/~myl/languagelog/archives/005497.h...

[aangjie]

I upvoted your comment because it is a real pain. But I don't agree with blaming the Linux kernel developers for it. Neither do I think it's analogous to this particular discussion either, because a, Linux kernel developers can optimize/prioritize their kernel code as they please. b, In this case, AMD is submitting a patch to make it easier for them to support linux for their GPU. So the "ball is in their court" to find a solution the community finds acceptable.

Your case is about porting code between different OS kernels.

[aseipp]

dave airlie forces people at gunpoint to only write software for Linux and nothing else, meaning HEROES like myself have to pick up the slack. fact-a-mundo. it's also perfectly well known that if you dump 100,000 lines of code on a project, they are MANDATED BY LAW to accept it and not have standards to abide by. who do these jerks think they are?????????

i'm definitely not mad and bitter about Linux in any way, grasping at straws in an attempt for relevance. i promise you. pinky swear.

[throwaway3322]

Austin, can you expand on the instances you reference where you've had to pick up the slack? Was it something in GHC?

[lodi]

Re-read it sarcastically...

[ionforce]

I don't understand what this means.

[bb611]

I believe X86BSD is referencing the fact that Dave Airlie works on Red Hat Linux

[solarengineer]

Ah, I believe he is talking about the general pain all non-linux distros have faced over the years where we have to painfully keep replacing linuxisms in the code with portable code.