Netgpu and the hazards of proprietary kernel modules
lwn.net
lwn.net
> "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/
I knew i forgot someone THANKS!
EDIT: Ahh looking at you comment's you are a anti-bsd troll, so dont waste time searching for proof.
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? :)
The idea that they 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)
But please come up with real examples, did linux devs ever like "smashed 16yo"?
Also, why don't you set an example and express yourself politely too?
Because i can:
https://www.youtube.com/watch?v=caOq2rDe_C0
EDIT: Oh yeah a attack on a culture...what culture? The Fuck you NVIDIA but we send you firmware because otherwise nothing will work? That Culture?
As far as I can see, if you have to say "no" doing so politely has no downside, whereas behaving like this clearly has some.
"...you really disqualify yourself from kernel work. Please really just go away and stop this crap."
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.
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.
"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.
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.
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.
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.
Greg KH called this trolling, and he isn't one to mindlessly throw around insults.
Dijkstra would probably have said something like that, though he'd have crafted a pithier way of saying it.
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.
Telling someone they "should not be anywhere near Linux kernel development" and to "just go away" is degrading and contemptuous.
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
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.
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.
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.
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.
Industrial Linux users are not using their gaming cards.
You brought up Linux gamers, so I pointed out the Linux gamer market is miniscule because most gamers are on Windows.
>Industrial Linux users are not using their gaming cards.
Okay? The thread never said anything about gaming cards. Again, you're the one who brought up gamers in the first place.
Not for the matters of the Linux driver. Whether Nvidia cares is another question.
> The thread never said anything about gaming cards
And Linux gamers is the main driving force behind open drivers. Industrial users are too slow to have effect on that.
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.
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.
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.
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.
That's starting to sound like DRM.
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.
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.
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?
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...?
This is not what is happening, you're still free to modify the Linux kernel in any way you want.
> ... 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?
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.