Good news, seems like the GNU Linux-libre team has enough to do anyhow … (https://lists.gnu.org/archive/html/info-gnu/2020-08/msg00001...)
Netgpu and the hazards of proprietary kernel modules
51–60 of 104 posts
Re: Netgpu and the hazards of proprietary kernel modules
#52Earlier quoted context omitted.
How is that comment toxic? The code this guy was trying to get merged in was toxic, and the kernel developer rightly told them to stop trying to push this harmful code.
It's degrading ("toxic") to tell a contributor they don't belong in kernel development with comments like the above and the follow-up: "...you really disqualify yourself from kernel work. Please really just go away and stop this crap."
1. They're not a contributor. Not yet, anyway.
2. How degrading do you consider the submission?
As can be seen from the patchset, there's no conceivable way it could be built into the kernel without having the kernel build depend on proprietary headers, effectively disqualifying it entirely. This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It's either utter carelessness, stupidity, or outright malice to ask for something like this to be included into a loudly-and-clearly GPL-licensed kernel.
Re: Netgpu and the hazards of proprietary kernel modules
#53Earlier quoted context omitted.
It's not DRM, the entire check basically amounts to "if (strcmp(license, "GPL") != 0)", where "license" is a user supplied string.
DRM is DRM regardless of how trivial it is to bypass. What you should really be asking yourself is why such code even exists, since it is very much against the spirit of free software. Linux(s) has the right to not accept contributions, but to effectively get in the way of others who do want to make the changes despite them being perfectly acceptable and perhaps even encouraged by the GPL just seems very wrong to me.
> What you should really be asking yourself is why such code even exists
I think TFA makes that abundantly clear. Repeating here for your benefit:
"Symbols exported as GPL-only by the kernel are made unavailable to proprietary modules, but there has always been a bit of a loophole in how this is enforced.
"Hellwig's patch does not entirely close this loophole, but it makes exploiting it a bit harder.
"This episode, where a proprietary module helped send a significant development project in the wrong direction and makes it nearly impossible to implement this functionality in a way that works with all GPUs, demonstrates one of the reasons why the development community sees those modules as being harmful.
> since it is very much against the spirit of free software.
I fail to see how this is even remotely the case. Or do you consider copyleft licenses to be "against the spirit of free software"?
> ... and perhaps even encouraged by the GPL
The point of the patch is, literally, to help enforce the GPL.
From TFA: "With this patch applied, any module that imports symbols from a proprietary module is itself marked as being proprietary, denying it access to GPL-only symbols. If the shim module has already accessed GPL-only symbols by the time it gets around to importing symbols from the proprietary module, that import will not be allowed."
Linking to a proprietary module should make your code proprietary too. If you're proprietary, you shouldn't be able to link against GPL code anyway. Isn't _that_ the point of copyleft?
Re: Netgpu and the hazards of proprietary kernel modules
#54Nvidia should stop fooling around and support Nouveau. Their dinosaur blob driver approach is not something anyone needs.
Unfortunately it's something that all their customers who use it today need, and are quite satisfied with using. As long as their customers have no problems using the prop driver, nvidia has no reason to stop pushing it.
Re: Netgpu and the hazards of proprietary kernel modules
#55Nvidia should stop fooling around and support Nouveau. Their dinosaur blob driver approach is not something anyone needs.
Unfortunately it's something that all their customers who use it today need, and are quite satisfied with using. As long as their customers have no problems using the prop driver, nvidia has no reason to stop pushing it.
> Unfortunately it's something that all their customers who use it today need, and are quite satisfied with using.
Doesn't look like it: https://www.gamingonlinux.com/index.php?module=statistics&vi...
Nvidia usage among gamers on Linux at least is gradually dropping. Blob is causing all kind of problems (especially in Wayland session use cases), while not offering any advantages over open drivers from AMD.
And with Intel coming out with gaming GPUs soon too, I'd expect this trend to accelerate even.
Re: Netgpu and the hazards of proprietary kernel modules
#56Earlier quoted context omitted.
It's degrading ("toxic") to tell a contributor they don't belong in kernel development with comments like the above and the follow-up: "...you really disqualify yourself from kernel work. Please really just go away and stop this crap."
1. They're not a contributor. Not yet, anyway. 2. How degrading do you consider the submission? As can be seen from the patchset, there's no conceivable way it could be built into the kernel without having the kernel build depend on proprietary headers, effectively disqualifying it entirely. This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It…
> As can be seen from the patchset, there's no conceivable way it could be built into the kernel without having the kernel build depend on proprietary headers, effectively disqualifying it entirely.
Then just disqualify it, cite the reasons for why, and move on. No need for attacks, no need to tell the other person to fuck off. There's enough badness in the patch that you don't need to resort to criticizing the submitter.
Re: Netgpu and the hazards of proprietary kernel modules
#57Ignoring the legal spat, it's interesting that someone is trying to direct packets at the GPU. In a way, GPUs and high-end routers have similar demands: execute the same code in parallel on huge numbers of data units - and I understand that there are also similarities in the microarchitecture. So it wouldn't surprise me if you could implement a high end router using a GPU. All those floating-point ALUs would be sitting idle, of course, so it might be an expensive solution; although the economies of scale in GPUs might be larger than routers, so it might work out. Devil is in the detail, of course.
Re: Netgpu and the hazards of proprietary kernel modules
#58Earlier quoted context omitted.
It's not DRM, the entire check basically amounts to "if (strcmp(license, "GPL") != 0)", where "license" is a user supplied string.
DRM is DRM regardless of how trivial it is to bypass. What you should really be asking yourself is why such code even exists, since it is very much against the spirit of free software. Linux(s) has the right to not accept contributions, but to effectively get in the way of others who do want to make the changes despite them being perfectly acceptable and perhaps even encouraged by the GPL just seems very wrong to me.
>since it is very much against the spirit of free software
I'm not sure what you mean. This is a check that (among other things) helps downstream users avoid violations of the GPL, which is a free software license.
Re: Netgpu and the hazards of proprietary kernel modules
#59Earlier quoted context omitted.
Unfortunately it's something that all their customers who use it today need, and are quite satisfied with using. As long as their customers have no problems using the prop driver, nvidia has no reason to stop pushing it.
> Unfortunately it's something that all their customers who use it today need, and are quite satisfied with using. Doesn't look like it: https://www.gamingonlinux.com/index.php?module=statistics&vi... Nvidia usage among gamers on Linux at least is gradually dropping. Blob is causing all kind of problems (especially in Wayland session use cases), while not offering any advantages over open drivers from AMD. And with I…
Their gamer customers are mostly on Windows. Their Linux customers use their cards for ML and CUDA.
Re: Netgpu and the hazards of proprietary kernel modules
#60Earlier quoted context omitted.
DRM is DRM regardless of how trivial it is to bypass. What you should really be asking yourself is why such code even exists, since it is very much against the spirit of free software. Linux(s) has the right to not accept contributions, but to effectively get in the way of others who do want to make the changes despite them being perfectly acceptable and perhaps even encouraged by the GPL just seems very wrong to me.
> What you should really be asking yourself is why such code even exists I think TFA makes that abundantly clear. Repeating here for your benefit: "Symbols exported as GPL-only by the kernel are made unavailable to proprietary modules, but there has always been a bit of a loophole in how this is enforced. "Hellwig's patch does not entirely close this loophole, but it makes exploiting it a bit harder. "This episode, w…
I fail to see how this is even remotely the case. Or do you consider copyleft licenses to be "against the spirit of free software"?
Actively making it harder for people to modify software for their own use is definitely against the spirit of free software! Copyleft has nothing to do with that, and is only about distribution of your modifications.
The point of the patch is, literally, to help enforce the GPL.
Once again, the GPL places restrictions on public distribution, not private use/modification/etc.
It seems there is this insanity where some people want to split the world in half between "free" and "non-free", and such things are entirely ridiculous in reality. If they had their way I'm sure we wouldn't even be allowed to talk to them if we had ever used proprietary software at all. IMHO such antagonism is really bad for free software too. It reminds me of what Stallman did with GCC... and look how well that turned out (Clang etc.)
From TFA: "With this patch applied, any module that imports symbols from a proprietary module is itself marked as being proprietary, denying it access to GPL-only symbols. If the shim module has already accessed GPL-only symbols by the time it gets around to importing symbols from the proprietary module, that import will not be allowed."
Your code is running in kernel mode, which already means you can jump, call, and modify whatever you damn well want to! This is why I view such silly exercises as needless bureaucracy (and complexity). If official Linux wants to keep proprietary code out of the kernel, that's their right, but don't go out of your way to fight everyone else.
It's my computer, I get to run whatever code I want to. Isn't that what free software is about...?