Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netgpu and the hazards of proprietary kernel modules

lwn.net

Post reply on HN
Print view View original

41–50 of 104 posts

Re: Netgpu and the hazards of proprietary kernel modules

#41

Post by microcow »

deft wrote: post #33
microcow wrote: post #23

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!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

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

Re: Netgpu and the hazards of proprietary kernel modules

#42

Post by userbinator »

cycloptic wrote: post #8
userbinator wrote: post #5

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. That's starting to sound like DRM.

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.

Re: Netgpu and the hazards of proprietary kernel modules

#43

Post by ska »

beefee wrote: post #30
microcow wrote: post #23

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!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

As a user and downstream developer, I'm glad that the Linux maintainers are committed to maintaining a sound architecture. The idea that they need to be more polite about rejecting low quality work is puzzling to me.

What is puzzling to me is the idea that being rude contributes anything to the cause of maintaining a sound architecture.

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.

Re: Netgpu and the hazards of proprietary kernel modules

#44

Post by stefan_ »

kabdib wrote: post #34
microcow wrote: post #23

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!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

> "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…

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.

Re: Netgpu and the hazards of proprietary kernel modules

#45

Post by boomboomsubban »

q3k wrote: post #27
microcow wrote: post #23

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!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

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.

Re: Netgpu and the hazards of proprietary kernel modules

#47

Post by sillysaurusx »

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.

Re: Netgpu and the hazards of proprietary kernel modules

#48

Post by jeffbee »

beefee wrote: post #30
microcow wrote: post #23

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!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

As a user and downstream developer, I'm glad that the Linux maintainers are committed to maintaining a sound architecture. The idea that they need to be more polite about rejecting low quality work is puzzling to me.

Imagine believing that Linux has a "sound architecture".

Re: Netgpu and the hazards of proprietary kernel modules

#49

Post by mroche »

deft wrote: post #35
IshKebab wrote: post #9

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

Re: Netgpu and the hazards of proprietary kernel modules

#50

Post by Corazoor »

microcow wrote: post #23

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!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…

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.

Post reply on HN