Netgpu and the hazards of proprietary kernel modules • Hacker News Board

Re: Netgpu and the hazards of proprietary kernel modules

#101

Post by shmerl » Sun, Aug 16, 2020, 3:36 AM UTC

Arnavion wrote: post #100

shmerl wrote: post #99

Earlier quoted context omitted.

But we were discussing Linux users. Windows market is irrelevant for that. Industrial Linux users are not using their gaming cards.

>But we were discussing Linux users. Windows market is irrelevant for that. 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.

> The Linux gamer market is miniscule

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.

Re: Netgpu and the hazards of proprietary kernel modules

#102

Post by hvis » Sun, Aug 16, 2020, 10:50 AM UTC

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…

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.

Re: Netgpu and the hazards of proprietary kernel modules

#103

Post by R0b0t1 » Mon, Aug 17, 2020, 4:31 PM UTC

ska wrote: post #43

beefee wrote: post #30

Earlier quoted context omitted.

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.

Some people don't "get it" unless you at least try to appear rude. It's possible to waste a lot of time by not properly telling people off.

Re: Netgpu and the hazards of proprietary kernel modules

#104

Post by ska » Mon, Aug 17, 2020, 11:14 PM UTC

R0b0t1 wrote: post #103

ska wrote: post #43

Earlier quoted context omitted.

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.

Some people don't "get it" unless you at least try to appear rude. It's possible to waste a lot of time by not properly telling people off.

In my experience being clear is always enough here, being rude is not needed.