It seems reasonable to reject the patch for technical and legal reasons, but it's pretty disappointing to see toxic comments from prominent kernel developers like:
> "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!"
While I agree that these responses are rude, patches like this are the lkml equivalent of taking a dump in someones backyard...
It might very well be that the submitter didn't know that, the documentation on what will be flat out rejected is not very explicit.
But a compile-time dependency on a non-gpl module should be very self-evident, and the documentation explicitly asks people to go and learn about how the GPL works...
Revealing that as Patch 21 of 21 just adds insult to injury. Wasted a lot of peoples time with that one.
The fact that the module in question is from nvidia further shows that the submitter just had no idea of the histoy and culture of the linux developer community.
And that is the charitable Interpretation...
The kernel developers have to fend off stuff like that constantly, some are probably pretty jaded by now, which leads to responses like that.
It's normal human nature, most service workers who have to deal with customers have similar problems, and some develop the same kind of behaviour.
If you don't outsource thinking to other people you actually won't get reponses like this.
No! A flawed patch is not the equivalent of "taking a dump" in someone's yard. Proposing a flawed patch is not a contemptuous act, it's not insulting, and it is not injurious. Treating it as such is the problem.
Telling someone they "should not be anywhere near Linux kernel development" and to "just go away" is degrading and contemptuous.
I feel like the difference of opinion you and us are having here are ultimately over the difference in perspective here. You label it as merely a "flawed patch". The original comment by the kernel dev that incited this whole debate isn't even directed at the flaw in the patch, so it kinda feels like you're arguing at cross purposes here.
No! Talking or writing about another person like that (in public) is shameful for that Guy and for that Hellwig Clown (the guy who lost against VMware) too. If you say something like that in private..ok, not nice but acceptable but NOT in Public that should be absolute clear for any decent human being.
Yeah, this sort of tone on LKML has repeatedly driven me away from trying to upstream my patches. I don't need handholding and hugs, but if I'm going to get unconstructive toxicity like this then I'd rather just keep carrying my local patchset around.
I would describe posting your code in 21 patches, the last of which makes it fairly obvious there will be legal issues as "unconstructive toxicity" as well. Particularly when submitting something for a kernel team in a company like Facebook.
All in all Linux (the kernel) has a really toxic environment. If you like a more friendly community and still want to work on a Kernel go to Net/Freebsd, Haiku or OmniosCE. With Linux (the kernel) you are not allowed to make mistakes or ask (stupid?) questions.
Just curios...why are you so against BSD's (looking at you comments) is it a Fanboy thing? Are you fighting also so hard witch distribution is the best? :)
> "Seriously? If you only even considered this is something reasonable to do
> you should not be anywhere near Linux kernel development. Just go away!"
A response like this would get you a serious talkin' to at just about any place I've worked. Possibly fired, if it was consistent behavior.
I don't care if you're Donald Knuth, Dennis Ritchie and Edgar Djikstra all rolled into one, act like a jerk and you're off of my Christmas list.
So what do you get for trying to upstream an entirely useless patchset that exists purely as a GPL workaround to enable the ever-proprietary NVIDIA driver? Do you realize that's spitting into the face of the very people trying to drive open-source software across the entire stack?
Greg KH called this trolling, and he isn't one to mindlessly throw around insults.
An “impolite no” is not just a ‘no’, and it’s the latter that was required and not the former. He could have ‘recommended’ that the whole patch-set be re-architected to avoid depending on the proprietary module. There was really no need (or any excuse really) for being so coarse.
>need to be more polite about rejecting low quality work is puzzling to me.
First, it's not low quality
Second, for sure you have to be polite if you don't pay him (but even when you do, you should)
Third, imagine a 16yo get smashed like that (not that i say he is) and what a devastating and demotivating thing that could be...welcome to the linux world
Overall, those Superstar Linux dev's are mostly ignorant borderline autistic assholes who can't develop a good Filesystem like XFS or ZFS from scratch, then moan about Nvidia, but work on a computer with around ~100 proprietary systems called firmware. One accusing the OpenBSD peoples for being masturbating security Monkeys just to say (4-6 years later) that they where right (a super rare occasion for a linux super star). You know what i like to say? FUCK YOU LINUX, FUCK YOU GNU (but not grep...gnu grep is nice)
There is one subtle fact that kernel contributors (as well as members of other "serious" free software project) have to make a point to avoid knowing the internals of proprietary software, in order to avoid any suspicion of copying the code, design, or willful patent infringement.
As such, submitting a patch that relies on such internals in third-party proprietary code and thus imparts a certain amount of knowledge about those internals to the reader might make the work life of the reviewers more difficult. So it is considered distinctly impolite.
I'm not 100% sure about the exact legal reasons/mechanisms involved, but this has come up previously during the review of Microsoft's DX12 patches for WSL.
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.
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.
It's ridiculous that the Linux community thinks it's normal to insult people and tell them to go away and never come back because they are "careless" or "stupid". Reject it (and maybe educate if you're feeling generous) but there's no reason to be a dick.
> 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.
As I have said already, which you seem to be ignoring:
"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.
----
In the end, all I have to say to you is:
If I walk up to you in the street and slap you in the face, unprovoked, surely the noble thing for you to do is to politely tell me off; but I will not hold it against you if you were to lose your cool and retaliate.
Neither carelessness, stupidity, or malice (over a patch!) warrants personal attacks. I wouldn't ever compare these to being slapped in the face, unprovoked, on the street.
A code maintainer's job is to curate, coordinate, help, and sometimes (in this case, notably) also gatekeep. If you can't stand the occasional terrible code and have to resort to personal attacks in order to vent off, or to feel better (or because you feel personally insulted) - then that seems to me that you're bad at your job.
If we're going with parallels - seeing this sort of behavior and excuses reminds me of people excusing police abuse. If you can't be cool and deescalate the occasional problem - maybe this job's not for you.
> Neither carelessness, stupidity, or malice (over a patch!) warrants personal attacks.
1. We both know it wasn't just "a patch". Downplaying what happened doesn't serve the discussion.
2. I do not see "If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" as a personal attack, but as an attack against _the behaviour_ that _deliberately_ wastes a lot of one's time. Note the _"if you ... considered this ..."_.
----
> I wouldn't ever compare these to being slapped in the face, unprovoked, on the street.
This is not the comparison I made. I compared the reactions of the offended and your comments on said reactions. Let me try again, in clear terms: I find it understandable when someone doesn't react calmly and politely to having a lot of their time _deliberately_ wasted and their principles attacked.
> ... the occasional terrible code ...
See, again, I think you're severely downplaying what happened. The LKML regularly sees "the occasional terrible code". This is not one of them. Not even close.
> ... this sort of behavior and excuses reminds me of people excusing police abuse.
That is a ridiculous comparison to make. The LKML does not exist to "protect and serve" the public, is not funded by the public, or even remotely responsible for law & order & safety & peace of the public.
It is a private group of like-minded people that happen to be open to public participation. If you go and take a dump on their lawn, don't be surprised at some harsh words thrown back at you.
And definitely don't compare a handful of harsh words that are easily brushed aside for gruesome physical brutality and blatant wilful murder.
> ... the occasional problem ...
Again, you are severely downplaying what happened. What was posted is not an example of "the occasional problem" — there's plenty of those in the lists. What was returned wasn't nearly as toxic.
ok, what you do when someone modifies the product you're using so you cant continue to use it the way you did before, and you cant fix it or alter it due to legal or community reasons? you move away to different product.
what the people who use/develop kernel would do when they become unable to modify large part of kernel code that is highly needed for their work?
business doesnt work like typical consumer, there is no "products" that they pick from the big market
It wasn't clear from the article, and I can't figure out the answer really, but I'm curious if this will impact any existing popular modules. For example the NVIDIA driver - is it affected by the symbol import limitation as proposed now?
Ignoring 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.
The gpl-shim loophole could be useful, actually. Having a gpl shim means that one could insert tracing code into such shim, helping reverse engineering with the goal of developing free drivers.
There was a module that used CUDA to accelerate operations in the Linux kernel a few years ago (but the author knew better than to try to mainline it). I think it was this one: https://github.com/wbsun/kgpu/
I'm starting to get mildly disappointed about this paradigm. GPUs have the hardware for very powerful dynamic parallelism, yet only CUDA supports that (since no GPU driver of note supports more than OpenCL 1.x). I'd much rather see the GPU-CPU pair used as a pair of nodes that are linked with a high-speed interconnect (PCIe), yet APIs apart from CUDA never moved much beyond the compute model of OpenCL 1.2.
I wonder if it’s somewhat similar to Linux developers refusing to support TCP Offload Engine functionality, inventing various excuses easily proven false by experiences with TOE support for other systems.
What's the best way to accomplish network card -> GPU streaming right now? Netgpu sounds handy. Is there an alternative, or was netgpu the only way?
If network -> GPU is fast enough, you might be able to stream your training data from a separate box. That'd be useful for massive datasets, e.g. training GANs on terabytes of photos.
I'm also interested in the reverse: GPU memory -> network, without passing through host memory. I've wanted to make real-time (>20 FPS) ML visualizations, streamed directly from the training box down to the user.
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.
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.
I must be misunderstanding, but isn’t that symbol access limitation entirely useless? If someone has the technical knowhow to develop a kernel patch set, they certainly have the capability to do so on a kernel they’ve recompiled without this limitation.
The purpose of it does not seem to be to stop anyone from ever doing this ever, but rather to discourage patch submitters from wasting upstream maintainer time with patches that can't be reviewed because they use one of these shim layers.
Sure, anyone can do that and it is entirely fair to use the software that way privately. The barrier is that they can’t distribute the resulting modules because no one else will have a kernel that has been modified this way.
NVIDIA is a source of the most kernel problems related to the proprietary drivers. Pure evil. They manage to intoxicate the ecosystem without even doing anything.
> The sad part is that, by all appearances, the goal of this work was not to add functionality for NVIDIA GPUs in particular. Lemon does not seem to be an NVIDIA employee; the patches included a Facebook email address.
That's a really weird conclusion given that it specifically targets nVidia GPUs, it's for machine learning, and everybody uses nVidia GPUs for machine learning.
I don't see what working for nVidia has to do with it. He works for a company that uses mountains of nVidia cards for ML.
> The sad part is that, by all appearances, the goal of this work was not to add functionality for NVIDIA GPUs in particular.
I don't see how that can be true given that it is designed to speed up ML, and only nVidia graphics cards are used for ML. Approximately nobody uses Intel or AMD.
Maybe they meant it wasn't written by an nVidia employee? But it's clearly intended to be used with nVidia GPUs in particular.
It uses an NVIDIA apis, its made for NVIDIA tasks (CUDA) and it was only ever designed to work on NVIDIA cards. Apparently being a Facebook employee means you can't have pro-NVIDIA anti-anything else intentions... even when that's clearly the case.
Apparently being a Facebook employee means you can't have pro-NVIDIA anti-anything else intentions... even when that's clearly the case.
That’s being a tad disingenuous. Developing a solution to an in-house use case while ignoring alternative platforms that you don’t use does not make one “anti-anything else”. For a business of Facebook’s scale (or any scale for that matter), would you or your manager approve of spending time on such a task? Unless it was simple, there was enough time, or there were known potentials of switching product lines, I would venture to guess: no.
However, trying to upstream such work without considering where it’s going in which the very last patch review of 21 shows the problem isn’t the brightest idea.
I feel like all this needless bureaucracy could've been avoided completely if Linux hadn't turned into a target for everyone to (try to) put code in. The GPL allows modification and redistribution, after all.
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.
One of the primary advantages for authors in contributing back code is to get their features/bug fixes incorporated so that they are maintained going forward and you don't have to maintain a separate code base yourself (i.e. saving work) If you maintain your own obscure fork, you lose many of the benefits of contributing code. This is particularly true for many for-profit companies: they want to forget about any driver work they contributed the second they stop making money selling it.
I'm sure Facebook has enough resources to maintain its own custom kernel with what it wants --- if it's not already doing so. Google might be doing the same too.
Sure, FAANG companies have enough resources to do pretty much whatever they want. The rest of the world doesn't, which is what I presumed 'target for everyone' was referring to.
It's close, but the key difference is it doesn't actually restrict the user, since you're both legally allowed and technically able to build and use a kernel without that code.
If you remove the DRM from your browser, then you can't watch some content anymore. That's not the case with this code. You can remove it with no loss of functionality.
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?
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...?
> ... for people to modify software for their own use
> ... private use/modification/etc
> It's my computer, I get to run whatever code I want to.
The patch changes none of that. The patch doesn't prevent you from disabling this restriction on your private builds.
It seems you still don't get the purpose of the patch. It is not designed to make _your_ private use difficult. It is designed to make _public_ contribution attempts like TFA that waste everyone's time again and again easy to push back against. TFA is not the first time something like this has happened. The kernel devs have repeatedly had to tell people off from trying to add proprietary-dependent or for-proprietary modules into the kernel. Adding a switch for GPL-and-non-GPL mixing makes that explicit and easy to catch.
> 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.
I don't know where this antagonism comes from, but it seems like you're missing the point. Try to look at the posting from their point-of-view. It wasn't that the poster used some proprietary software on their own, but that they forced said proprietary software on every reviewer on the mailing list. Surely, you understand the distinction?
>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.
> "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!"
https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@lst.de/