Linux Developers Still Reject NVIDIA Using DMA-BUF

[pingufunkybeat]

It doesn't matter what Alan Cox wants, courts have already stated that APIs are not covered by copyright or have you already forgotten the Oracle v. Google case where Java's API (gpl 2 same as the kernel, mind you) lost to Android?

Correct.

Google did a clean-room reimplementation of Java Virtual Machine, using the same API.

Nvidia can do a clean-room reimplementation of the Linux kernel, using the same API.

What they can't do is link proprietary code against GPL code. Google did not do this, they wrote their own code.

[pingufunkybeat]

What about firmware blobs the kernel is shipping with? Isn't that illegal?

They don't link against the Linux kernel, or run on the same hardware.

[johnc]

Nvidia can do a clean-room reimplementation of the Linux kernel, using the same API.

They will just do a "clean-room reimplementation" of the DMA buffer sharing mechanism they need, then everyone here will biitch that NVIDIA isn't using the common kernel code.

And TI will have their version... and Qualcomm... and Samsung... etc.

[entropy]

They will just do a "clean-room reimplementation" of the DMA buffer sharing mechanism they need, then everyone here will biitch that NVIDIA isn't using the common kernel code.

And TI will have their version... and Qualcomm... and Samsung... etc.

What I don't get, how would that allow to implement Optimus(TM) between an intel IGP and an Nvidia GPU?

[calubi]

What you have to remember is that NVIDIA is a business. The binary blob serves the needs of the commercial users who buy expensive hardware for Linux (read: HPC cluster users on enterprise linux distros) just fine, so where is the incentive to prioritize open-source drivers on Linux? Why does the lack of open-source support have to be a conspiracy against open-source instead of simply a lack of demand from commercial clients that pay the bills?

I just have to ask, why go on for 18 pages with the same arguments? I would love to see more open support as much as the next person, but this thread is just getting ridiculous. This thread is longer than most technical discussions about important Linux kernel subsystems! If you don't like NVIDIA's policies, then don't buy their hardware.

[johnc]

What I don't get, how would that allow to implement Optimus(TM) between an intel IGP and an Nvidia GPU?

I don't think Optimus is their primary intention with this. I think this is more about Tegra and Maxwell.

[entropy]

I don't think Optimus is their primary intention with this. I think this is more about Tegra and Maxwell.

Well, could be. I was too focused on Optimus.

[johnc]

Lol, optimus support in Linux will work out of the box with nouveau, intel, radeon, etc, since they are already using (?) or can use DMA-BUF/PRIME, while the blob will be left with crappy/hacky bumblebee crap.

Nvidia FAIL.

Yup. And you'll be able to play 2D Solitaire with it.

Nouveau FTW!

[johnc]

Lol, enjoy your bumblebee.

While the rest of us sit and enjoy our out-of-the box optimus support (DMA-BUF, PRIME), Wayland, etc.

That's okay, I have no interest in laptops.

I'll enjoy my discrete card playing the latest video games on Windows 7... while you enjoy your Wayland and etc.

[DaemonFC]

Lol, optimus support in Linux will work out of the box with nouveau, intel, radeon, etc, since they are already using (?) or can use DMA-BUF/PRIME, while the blob will be left with crappy/hacky bumblebee crap.

Nvidia FAIL.

I think that's the real meat of the kernel developer decision to keep Nvidia away from DMA-BUF. Why hand them something else that will be useful for them to harm people with (with their blob being proprietary and hazardous to system integrity)? Why give them more incentive to continue being parasites that never work upstream and just ship a blob of crap with a kernel glue layer later on?

It's not just about Free Software, either. Nvidia already exposes their users to many security problems, such as that example back in August. The TL;DR of that is (1) Nvidia knew about the problem for over a year because it had been privately reported, (2) The problem was a local root exploit that their blob facilitated due to unsafe use of /dev/shmem, and (3) they fixed it in a matter of days *after* one of the kernel developers released a proof of concept and embarassed them on Slashdot.

I have to assume that handing Nvidia another kernel interface to abuse will just lead to more bugs that expose many more nasty security problems when you use their blob driver on Linux.

As much as the kernel developers want to wash their hands of Nvidia and AMD's blobs that cause all sorts of weird errors (warnings, oopses, and panics), they still end up getting users that try to submit bug reports to upstream (or to their distribution) that were caused by having nvidia or catalyst loaded. Sifting through bug reports to decide that there's nothing you can do about it because it's not your bug and the proprietary software company that made the driver may or may not ever get around to fixing it is not "free", it wastes the time of people who have to triage bug reports. They will spend at least a minute or two just looking at the bug report, seeing that the user has Nvidia or Catalyst loaded, and deciding to render it INVALID.

They should make life as difficult as possible for Nvidia as long as Nvidia insists on being uncooperative. If the feature is something Nvidia really wants, then maybe they will open some of THEIR code to gain access to the kernel interface.

In the mean time, it's nice (in a spiteful sort of way) to do to Nvidia exactly what they've done to Nouveau for a change. "Nyah! Nyah! We do something cool and we're not going to let you use it!".