Linux Developers Still Reject NVIDIA Using DMA-BUF

[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!".

[Dan555a]

I won't blame the kernel devs for preventing Linux to become stuffed up with more proprietary software.

[johnc]

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.

You might want to recheck your facts on that one.

The rest of your post is one big crybaby rant. Who would even take Linux seriously if the kernel devs were as unprofessional as you're proposing? Sometimes I wonder what world some of you folks live in.

[DaemonFC]

You might want to recheck your facts on that one.

The rest of your post is one big crybaby rant. Who would even take Linux seriously if the kernel devs were as unprofessional as you're proposing? Sometimes I wonder what world some of you folks live in.

Their blob is incompetent, it has lots of problems, it creates many unsupportable issues, it exposes the user to security vulnerabilities that Nvidia never fixes. Did I leave anything out? I don't think Nvidia can be taken seriously.

[DaemonFC]

It's not like code quality really matters with Nvidia or Catalyst. What matters to them is hacking it up to run on the latest Ubuntu without crashing it so much that it's plainly obvious the user made a mistake when they installed it.

[asdx]

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!".

I couldn't agree more with you. Getting rid of the blobs and open sourcing EVERYTHING is the right thing to do, it might sound extremist, but there's no other way.

Open sourcing their drivers, providing specifications and helping nouveau/radeon is the right thing to do.

Intel is not losing any money by being cooperative with Linux and open source, Mesa, etc.

AMD/Nvidia should learn from Intel.

It's a great thing that the kernel devs are not providing DMA-BUF access to the blobs, I hope blobs die already.

[RealNC]

You are extremely confused.

1) You cannot put GPL software into the Microsoft Windows kernel. It's illegal. You can't put proprietary software into Linux either. It's also illegal.

3) There is nothing the kernel devs can do. They can NOT let Nvidia put their stuff in the kernel. The license prohibits it. They do not have the ability (or desire, but that's secondary) to change the license. Even if everyone on lkml agreed they wanted to, THEY CANNOT.

You are the one who is confused. No one said that NVidia is putting the blob in the kernel. It only uses a kernel API, they are not submitting the driver for inclusion in the kernel. NVidia does not want to put proprietary software in the Linux kernel. They also do not want to put GPL software in their proprietary driver. All they want is to interface with the kernel. You know, communicate with it. It is weird how the GPL can prohibit communication. I don't get it. To me, it looks like the kernel devs are trolling NVidia.

Also, by definition, you can't put GPL software in the Windows kernel, because there's no source code for the Windows kernel. Where would you put it? And why would you want to? You can just write a GPL Windows driver instead. You don't need to put it in the actual kernel (only Linux has that limitation where you're expected to put stuff in the kernel rather than just writing a driver like in the majority of other OSes.)

2) You can run any software using Microsoft's libc. You can run any software using glibc. Both are equally legal.

That's my point. The GPL has a special exception for this. Otherwise, it would NOT be possible to run GPL software on MS libc, and proprietary software on glibc.

The GPL wasn't written with kernels in mind though. The kernel should have provided an exception for external modules (like the NVidia driver) so that they can use kernel APIs.

[XorEaxEax]

With proprietary drivers. Unless you mean Intel, which is only able to run old games (L4D is an old game.)

How do you know Intel gpgpu are only able to run 'old games'? The drivers are improving (in part with Valve's help) and so will the core performance of gpgpu solutions.

High performance gaming on Windows means you can get 60FPS with high resolutions and maximum details on a demanding game released this year.

Lol, yes maybe Linux will never appeal to the hardcore ricer-gamers but seriously they make up such a small portion of the gameplaying world and in essence they have already moved on from the PC to the dedicated consoles, the vast majority does not have or require ricer performance in order to enjoy games. This is why the goddamn smartphones and pads are putting a serious dent no only onto pc gaming but also dedicated gaming consoles, this is also why Minecraft, a game written in Java with 3d graphics from the 90's can go on and become a huge seller. Linux doesn't need to have the best performance to be an option for gaming, it needs good-enough performance and of course the games (hello Steam!).

Why is it OK that I can run a GPL app on Windows, which links against Microsoft's C library, but I can't have a proprietary driver making use of an interface of a GPL kernel?

WTF are you babbling about? Microsoft's c-runtime-library (which incidentally is not part of the windows core installation, which is why programs keep installing them, leaving you with tons of versions on your harddrive) does not reside in Windows kernel anymore than glibc does, these are _user-space_ libraries.

The NVidia driver is a driver, and thus cannot work reliably outside kernel space.

So the proprietary NVidia driver is just a fidgment of our collective imagination then, as it cannot work, or are you saying it works but constantly crashes?

If you're not allowing proprietary vendors to use it in order to be able to offer support and stay competitive in the licensing policy of their choice, then you're being a bigot.

Why are the kernel devs 'bigots' and not the proprietary vendors? If you want to talk 'immoral' or 'bigot' then certainly proprietary vendors doesn't have a leg to stand on as the whole concept of not being able to use the hardware you've bought to it's full extent anywhere you please because the hardware vendor won't provide necessary information for you to do so f**king reeks of 'bigotry'. Yet you decide that the proprietary hardware vendors 'rights' are being trampled here because they aren't allowed dictate the terms in which they interact with the Linux kernel?? Are you f**king insane?

If NVidia isn't allowed to interface with the kernel, then Google shouldn't be allowed either. Much of the Android stack is proprietary, yet no one sees a problem with the Linux kernel sitting at the center of it.

If the proprietary parts are implemented in user-space there is no legal issue, just like with NVidia's proprietary driver. What is your point?

Hypocrites.

Bullshit, they are the exact opposite as they DON'T give NVidia any special favours, NVIDIA are hypocrites, they don't want to open their driver but they think they should have the benefits of open drivers, in other words they think the world owes them the right to have the cake and eat it.

[RealNC]

How do you know Intel gpgpu are only able to run 'old games'? The drivers are improving (in part with Valve's help) and so will the core performance of gpgpu solutions.

The hardware is lacking.

Lol, yes maybe Linux will never appeal to the hardcore ricer-gamers but seriously they make up such a small portion of the gameplaying world and in essence they have already moved on from the PC to the dedicated consoles, the vast majority does not have or require ricer performance in order to enjoy games.

I think you should take a look at the sale numbers of triple-A, graphically demanding titles over the years. How is that a "a small portion?"

WTF are you babbling about? Microsoft's c-runtime-library (which incidentally is not part of the windows core installation, which is why programs keep installing them, leaving you with tons of versions on your harddrive) does not reside in Windows kernel anymore than glibc does, these are _user-space_ libraries.

And? Where in the GPL's text is a distinction made between kernel and user space?

So the proprietary NVidia driver is just a fidgment of our collective imagination then, as it cannot work, or are you saying it works but constantly crashes?

Unless I missed the news, NVidia did not release a driver that uses DMABUF. If you've seen one, then yes, it would be a figment of your imagination.

Why are the kernel devs 'bigots' and not the proprietary vendors? If you want to talk 'immoral' or 'bigot' then certainly proprietary vendors doesn't have a leg to stand on as the whole concept of not being able to use the hardware you've bought to it's full extent anywhere you please because the hardware vendor won't provide necessary information for you to do so f**king reeks of 'bigotry'. Yet you decide that the proprietary hardware vendors 'rights' are being trampled here because they aren't allowed dictate the terms in which they interact with the Linux kernel?? Are you f**king insane?

I can use my hardware just fine. NVidia provides me with a working driver and good customer support. I gave them my money, so that's what I expected from them. AMD on the other hand, took my money, gave me no working driver and no good support. Instead, they tell me how they gave me a bunch of useless source code. What am I supposed to do with that? Write the drivers myself? I paid them so that they give me finished, well working drivers.

NVidia did that, AMD didn't. IMO, AMD is doing the immoral thing here, not NVidia. NVidia seems to respect their paying customers.

I don't care about licenses. I care that the products I buy with my money are working.

If the proprietary parts are implemented in user-space there is no legal issue, just like with NVidia's proprietary driver. What is your point?

The GPL does not make a distinction between user and kernelspace.

Bullshit, they are the exact opposite as they DON'T give NVidia any special favours

NVidia doesn't request special treatment. They request fair treatment.

NVIDIA are hypocrites, they don't want to open their driver but they think they should have the benefits of open drivers, in other words they think the world owes them the right to have the cake and eat it.

NVidia does not want to use open code in their drivers. Where did you see that? What they need is to communicate with the kernel.

Again: The GPL does not know what a "kernel" is. There's no distinction between a proprietary userspace program using a glibc API, and a proprietary driver using a kernel API.

[asdx]

You are the one who is confused. No one said that NVidia is putting the blob in the kernel. It only uses a kernel API, they are not submitting the driver for inclusion in the kernel. NVidia does not want to put proprietary software in the Linux kernel. They also do not want to put GPL software in their proprietary driver. All they want is to interface with the kernel. You know, communicate with it. It is weird how the GPL can prohibit communication. I don't get it. To me, it looks like the kernel devs are trolling NVidia.

Also, by definition, you can't put GPL software in the Windows kernel, because there's no source code for the Windows kernel. Where would you put it? And why would you want to? You can just write a GPL Windows driver instead. You don't need to put it in the actual kernel (only Linux has that limitation where you're expected to put stuff in the kernel rather than just writing a driver like in the majority of other OSes.)


That's my point. The GPL has a special exception for this. Otherwise, it would NOT be possible to run GPL software on MS libc, and proprietary software on glibc.

The GPL wasn't written with kernels in mind though. The kernel should have provided an exception for external modules (like the NVidia driver) so that they can use kernel APIs.

Fuck that.

Alan Cox was already clear, Nvidia can't and won't be able to use DMA-BUF. Period.

Linux devs trolling nvidia? Oh please, how hypocrite can some people be?

And Nvidia is the victim here? Yeah right.

Fuck them, they won't have DMA-BUF, period.

Specs for nouveau or GTFO.