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

61–70 of 104 posts

Re: Netgpu and the hazards of proprietary kernel modules

#61

Post by userbinator »

gnu8 wrote: post #14
vermilingua wrote: post #11

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.

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.

You can distribute the patch that undoes all this silliness too, which will also be GPL.

Re: Netgpu and the hazards of proprietary kernel modules

#62

Post by hvis »

userbinator wrote: post #42
cycloptic wrote: post #8

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

It is basically an automated check to flag modules that obviously violate GPL.

Re: Netgpu and the hazards of proprietary kernel modules

#63

Post by userbinator »

blihp wrote: post #21
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.

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

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.

Re: Netgpu and the hazards of proprietary kernel modules

#64

Post by userbinator »

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…

I wonder what Linus would say. "nVidia, fuck you!"? Maybe not this time.

Re: Netgpu and the hazards of proprietary kernel modules

#65

Post by microcow »

Corazoor wrote: post #50
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 w…

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.

Re: Netgpu and the hazards of proprietary kernel modules

#66

Post by blihp »

userbinator wrote: post #63
blihp wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Netgpu and the hazards of proprietary kernel modules

#67

Post by cycloptic »

userbinator wrote: post #60
pritambaral wrote: post #53

Earlier quoted context omitted.

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

>Actively making it harder for people to modify software for their own use

This is not what is happening, you're still free to modify the Linux kernel in any way you want.

Re: Netgpu and the hazards of proprietary kernel modules

#68

Post by solidasparagus »

pritambaral wrote: post #52
microcow wrote: post #41

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

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.

Re: Netgpu and the hazards of proprietary kernel modules

#69

Post by qubex »

nix23 wrote: post #29
non-entity wrote: post #26

Earlier quoted context omitted.

Can confirm: Haiku, FreedBSD, NetBSD, and DrangonflyBSD kernel communities have been quite friendly and helpful.

>DrangonflyBSD I knew i forgot someone THANKS!

All half-dozen of us thank you for thinking of us. ;)

Re: Netgpu and the hazards of proprietary kernel modules

#70

Post by [deleted] »

stefan_ wrote: post #44
kabdib wrote: post #34

Earlier quoted context omitted.

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

[deleted]
Post reply on HN